Jump to content

Wikipedia:Village pump (proposals)/Archive 117

Add links
From Wikipedia, the free encyclopedia
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

Collapse/show image, and default state via tag.

Images are fantastic but oftentimes they are only secondary to understanding a concept and can in many situations be off-putting.

For example, I was reading the page on anal fissures earlier today and came face-to-face with a picture of an infected anal wound. Naturally, this image is appropriate to the article and it feels equally natural that there should be a picture in the article. However, why not make it so that editors can have images collapsed by default, and a simple "show image" button to load it in? Naturally this would not be implemented on every page across wikipedia but giving editors the option to do this would vastly increase readability of a lot of pages, especially in the medical section of Wikipedia. I may be interested in the mechanics of an infected wound but very rarely do I have a hankering to view infected wounds.

I have many friends who have an aversion to seeing decomposing corpses, infected wounds, etc, but would still love to read up on the subjects. Implementing such a feature would promote the reading of many undervalued articles who are otherwise avoided because of images that may make people nauseous.


I can see why some people might be against such a feature, but for me and a lot of people it would make Wikipedia much more enjoyable to read through, and thus also bolster our knowledge in many diverse areas. — Preceding unsigned comment added by 109.228.137.59 (talk) 17:43, 13 December 2014 (UTC)


collapse/show is purely JS feature (well, some CSS may also be involved). can you point to, or create, a JS script that will demonstrate what this proposal means in practice? thx, peace - קיפודנחש (aka kipod) (talk) 21:18, 13 December 2014 (UTC)
What about the various collapse templates? Oiyarbepsy (talk) 02:39, 15 December 2014 (UTC)
A while back I made a user script to hide potentially-offensive images. Users with accounts might find it useful. Anomie⚔ 13:38, 16 December 2014 (UTC)

RfC: alternative to RfA: appointment of administrators

Consensus is clearly against this idea, so there is no point in continuing discussion. Non-admin closure. Oiyarbepsy (talk) 01:07, 22 December 2014 (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.

After much discussion on this page about the future of the RfA process, I'd like to propose a new alternative process for granting administrator status. This proposal is the product of discussion both on this page, and at the page I'll link in just a moment. It is proposed that the Wikipedia community create a body called the Administrative Standards Commission (ASC) to appoint administrators in parallel to the existing RfA process. The text of this proposal can be found at the link I've just provided. The talk page of that proposal is where it was discussed and drafted. Should we implement this proposal as specified at the proposal page? RGloucester — ☎ 00:48, 26 November 2014 (UTC)

Discussion (alternative to RfA)

  • I dont like the idea of creating more bureaucracy to deal with this. It seems to me that it just bureaucratizes the problem instead of solving it. What I like about the proposal is that the "bureau" also proposes desysopping, presumably with some weight so that it is actually acted upon. I think it would be a better idea to make the process more participatory, but less onerous. The problem is not broad participation in deciding who gets the tools. It is the bar that needs to be lowered. Nonetheless I am pretty much willing to try anything new at this point so I may end up supporting this proposal.User:Maunus ·ʍaunus·snunɐw· 01:03, 26 November 2014 (UTC)
I understand the reservations of bureaucracy creep, but, at the same time, creating some sort of board to deal with unforeseen circumstances as they arise could reduce the number of specific qualifications under unusual circumstances which would probably have to be itemized for a broader "automatic" proposal to pass. John Carter (talk) 01:26, 26 November 2014 (UTC)
No, "broad participation" is the problem, because it turns administrators into politicians, a role they should not be playing. Administrators should be technocrats, carrying out tasks necessary for the maintenance of the encyclopaedia, in line with the principle of "no big deal". Technocrats cannot possibly carry out their duties to the extent necessary in a climate where they will be strung up in front of a mob. We don't want administrators who are of a lesser quality, merely we want administrators who can do their jobs appropriately. The present system patently discourages those who are best at doing these jobs from ever running for adminship. Removing the mob from the equation is the appropriate way to solve this problem. We need to put our trust in representatives, elected by the community. RGloucester — ☎ 02:17, 26 November 2014 (UTC)
If that is the reasoning then I cannot support this proposal. The "not politicians" argument makes no sense since you are exactly proposing a board of elected "politicians" to appoint dmins instead of just appointing them directly through election. That simply moves the problem by adding an additional level of bureaucracy. The reason admins get embroiled with "politics" is because by necessity they deal directly with users and exercise power. They can no more be "technocrats" than law enforcement officers can - they are in their very essence a political class. Your proposal solves none of the problems you or I see (which I clearly not the same) and it adds the problem of an other small clique of powerful users who make decisions on the behalf of others. Nothing could be further form the spirit of Wikipedia. Back to the drawing board. User:Maunus ·ʍaunus·snunɐw· 02:27, 26 November 2014 (UTC)
That's the point, fellow. We must separate the politicians from the administrators, which is how government does it. Politicians appoint administrators on behalf of their electorate. This is because people that carry out technical work need to be able to do so without being taxed by political manoeuvring. Likewise, that's what we'd do here. Administrators are patently not politicians, nor should they be, neither is a constable a politician. Politicians are those that trade in discourse. Administrators should not trade in discourse, nor should constables. They should carry out the tasks needed to maintain the encyclopaedia, and to curtail disruption to editorial processes. They are trusted by the community to do this. They exercise their power on behalf of the community in this way. When a constable is forced to run for election, however, he becomes beholden to populism, to bargaining, and to politics. No longer will the quiet technocrat do the job well, but instead, the gregarious politician will do the job poorly. We need to return adiministration to its roots, here. Administrators began as technocrats, and they should remain as such. RfA has moved us away from that ideal. This proposal allows us to get back to our roots. It is anything but far from the "spirit of Wikipedia". In fact, it preserves the encylopaedia in away that RfA never can. Being an administrator should be "no big deal", and this proposal enshrines that principle. RGloucester — ☎ 02:36, 26 November 2014 (UTC)
It does entirely the opposite. It makes it a requisite for admins to suck up to a small clique of powermongers. It is this kind of system that leads to Feguson and Ayotzinapa in the real world.User:Maunus ·ʍaunus·snunɐw· 03:28, 26 November 2014 (UTC)
No "power-mongers" are involved. Commissioners would be elected by the community, in the same manners as Arbitrators. They'd be trusted, for that reason, just as Arbitrators are. They would not have any power over anyone. The only power they'd have is to accept applications for administrative rights, and to vet candidates for adminship. RfA would continue exist as a venue, concurrently. Democracy is rarely the answer to any problems, not least technical ones. Populism is our a problem, this Commission is the solution. However, I fear you are merely standing on a soapbox, and haven't read the proposal, so I shan't respond to you further. RGloucester — ☎ 03:36, 26 November 2014 (UTC)
I've read it thanks for the confidence. "Democracy is rarely the answer to any problems" describes very well where you are coming from and why you and I will never see eye to eye. I honestly don't know why people with that outlook would even be evolved in this eminently democratic project. Certainly I will stand on a soapbox if that is what it takes to stop people with ideas like yours from removing the singlemost sane and reasonable aspect of this project.User:Maunus ·ʍaunus·snunɐw· 03:51, 26 November 2014 (UTC)
I don't consider this project democratic. Wikipedia is not a democracy, as we're oft told. Wikipedia is a compendium of knowledge, and I happen like writing a bit of prose here and there. We have stringent editorial guidelines, and fight we fight for quality, rather than quantity. As guardians of knowledge, we must discriminate. Regardless, democracy is rarely sane. It works as a check on the apparatus of power, but it is not capable of exercising that power on its own. People like to think, these days, that they're special, that they're an "individual" in the liberal sense. They fragment themselves from the totality of human reality, which causes an intense fragmentation of society. This is evident in every part of our contemporary society, and is evident here. People put their own "right to decide" over what's good for the project. This results in the disaster we now have at RfA, and elsewhere on this project. We must reform these processes to remove populism the equation, and focus on the collective interest of our fair encyclopaedia. This proposal does that. RGloucester — ☎ 04:45, 26 November 2014 (UTC)
Sounds like cryptofascist "dark enlightenment" crap to me.User:Maunus ·ʍaunus·snunɐw· 05:34, 26 November 2014 (UTC)
I've never heard of either of those terms, but I do know that I am certainly not a fascist in any form. I'm a Marxist, if you will, and I believe that the interest of the collective is of greater importance than the interest of the individual. Working for the common good requires that we recognise our collectivity. That applies here as much as anywhere. In fact, the internet seems to give the individual outsize importance, as so many usual human urges to yield to the collective are suppressed by the computer screen's lack of humanity. However, I digress. RGloucester — ☎ 05:43, 26 November 2014 (UTC)
Then substitute stalinism for the desired effect. The result is the same, a select ruling class of "technocrats" keeps the unruly masses in order for the sake of the greater good. Not something I would ever lend my voice or vote to.User:Maunus ·ʍaunus·snunɐw· 05:54, 26 November 2014 (UTC)
The commissioners would be elected. They would not materialise out of thin air, or take control with swords and guns. I liked Mr Stradivarius's suggestion below, which is that one could run for election if one really has such concerns. Regardless, I don't think going on about the spectre of Stalinism is likely to be productive. RGloucester — ☎ 05:59, 26 November 2014 (UTC)
Since this is a major proposal, we should find a way to widely publicize it. Perhaps we could add this proposal to MediaWiki:Watchlist-details? --Biblioworm 02:52, 26 November 2014 (UTC)
I don't know anything about that. I'm now demoralised by the misconceptions above, so forgive me whilst I vacate this forum and allow others to comment. RGloucester — ☎ 02:54, 26 November 2014 (UTC)
Just wanted to note that I've added this discussion to Template:Centralized discussion. --Biblioworm 03:38, 26 November 2014 (UTC)
  • What exactly would be the limits of this ASC? They'd obviously be able to appoint the administrative toolset. Would they be able to revoke access to the administrative toolset if an issue where to arise? What would be their limits in regards to the sets of tools such as crat, OS, CU, TE, etc? I understand there seems to be a rush to offer an alternative to RfA based on the slew of recent proposals and RfCs on the topic, but I want to make sure I have a firm understanding of exactly what such a new "committee" would have authority to do. I'd also like to understand better what the set of board members for such a committee might look like as in representatives for editors with various interests and abilities. — {{U|Technical 13}} (e • t • c) 03:06, 26 November 2014 (UTC)
Please read the this section, which makes it clear as to what their duties would be. At first, if the establishment was approved, they'd only be able to appoint administrators, and also to search for candidates. The commission would be composed of both administrators and non-administrators, in line with this section. If you read the implementation section, it says that the powers of the Commission could be expanded to include review of administrative action at a later date. This would not be included in their initial duties. RGloucester — ☎ 03:14, 26 November 2014 (UTC)
  • Thank you, those links to specific sections was very useful. Couple more questions I didn't see addressed in those sections. What would the thresholds be for various things such as appointment to the committee, the threshold for which requests hold "merit", and threshold for agreement to appoint (or other final decisions). I'm thinking like the minimum 50% required for ArbCom appointment and the 70%ish support for the current RfA system. I'm also thinking the threshold for "merit" should be set relatively low to allow discussion. Would there be any any requirement for a potential grantee for the administrative tools have to accept the toolset (I know it may sound silly to some, but I think this question has merit based on the number of editors who have been given access to other user groups without requesting them and have never used the tools or have quit editing all together)? — {{U|Technical 13}} (e • t • c) 03:41, 26 November 2014 (UTC)
The elections are meant mimic ArbCom elections, as it says in the proposal. The threshold for merit would be decided by the commissioners, as part of their rules of order. The proposal provides for the idea that the first commissioners would establish rules of order, so that the commission could function. They'd be constrained by this framework, but they'd be free set-up their own workings. Of course, if someone didn't want the tools they wouldn't be made to take them. RGloucester — ☎ 04:00, 26 November 2014 (UTC)
  • Thank you for your candid answers to my questions about this proposal. That said, I'm unmoved by this proposal in either direction. I've recently started helping out at WP:ANRFC and have found that I really enjoy reading all of the arguments in both directions and closing discussions. That said, I'd be happy to contribute to the closing of this discussion when that time comes. — {{U|Technical 13}} (e • t • c) 04:18, 26 November 2014 (UTC)
  • I sort of like the idea in theory but see a some issues with the setup. Here are my thoughts:
    1. One is that it solidifies the admin vs. non-admin thing with the make up of the board. While I realize I am probably in the minority here for the most part the admin bit is really no big deal even if we make it that way. By setting the makeup to be current admin vs. not an admin we would end up codify that perception. I would think a better metric would be to mostly consist of editors that have successfully nominated someone else for admin. I believe nominators don't necessarily have to be admins, so it still allows "outside" views, but it also would encourage people to nominate good candidates if they want to get on such a board. It also means that people deciding on the board have a better idea how potential members would evaluate successful admins.
    2. Another issue is that thirteen seems like a bit large a group, while an odd nunber is good if straight forward majority voting is used. But given that the group is intended to be an alternative to RfAs and that anyone that tries can still go through an RfA or possibly try again after a period of time, a veto system might work better. Say a much smaller board of 5 with all having veto power. This means that the board can quickly skip candidates as soon as someone vetos and also allows for deeper investigation as board members should be able to prove why someone makes a candidate or what concerns that have to another panelist. If the board deadlocks and fails to promote any candidates in X time a new board should be elected.
    3. I'd suggest such a system start small, with a limited rate of mop hand outs if it is formed so that the community can judge the effectiveness.
    4. I'd also split searching for candidates off from the duties of the board. The board should be able to appoint clerks who would do searches for potential candidates ( besides the self-submitted ones ) and would do some of the grunt work research on the candidates. This leaves a leaning central board that can focus on the issues while off-loading much of the grunt work to volunteers. PaleAqua (talk) 03:50, 26 November 2014 (UTC)
Thanks for your suggestions. I think it is essential that non-administrators have representation on this Commission, to enshrine the principle of "no big deal". Administrators and non-administrators must be considered equal, and this proposal makes that clear. I originally had a smaller group, seven, as the number of commissioners. However, we realised that a larger group is necessary, because there may be commissioners who resign, or are absent, which frequently happens on the Arbitration Committee. For these reasons, I think thirteen is a good number, because it ensures that the smooth functioning of the commission won't be hampered by a few absences. Searching for candidates was the original purpose of this Commission. That's one the benefits of having thirteen commissioners, I'd say. As it says in the proposal, they'll establish their own rules of order, and whatever. They may decide to delegate power to certain commissioners, or to hire clerks. That's for the commissioners to decide amongst themselves. RGloucester — ☎ 03:57, 26 November 2014 (UTC)
I think this idea has merit. Debresser (talk) 10:39, 30 November 2014 (UTC)
  • Not sure what to make of this proposal. I do remember Jimbo once said that RfA was a "broken process" or something like that. A logical replacement would be desirable, but the idea of a committee has its ups and downs. The main issue with RfA is that it has become too daunting that even the supposed "best of editors" are afraid to go through the fiery hounds of hell, er, RfA. Putting the decision to give someone the mop to the community has the benefit in that the community is essentially the one that gets served by the sysops, not the other way around. Having a committee that separately appoints administrators, therefore, would seem very bureaucratic and a lot of WP:NOTBUREAUCRACY would be hurled across the room, and the community will not be pleased if someone who had the tools capable of damaging the entire website was selected by a small group of people. On the other hand though, it would otherwise keep hater votes and votes cast by people that don't do a thorough check at bay, and I personally think it will reduce the amount of good editors that are scared off by RFA. --I am k6ka Talk to me! See what I have done 19:20, 27 November 2014 (UTC)
  • Has anyone asked the WMF if they would allow this process, in the past Philippe has said that an editor would need to pass an "RFA or RFA-identical process" (here) before being allowed to have access to deleted revisions so this proposals seems to be a non-starter from the get go. Unless WMF Legal change their mind, I can't see a reason not to close this discussion. Callanecc (talk • contribs • logs) 02:27, 1 December 2014 (UTC)
    This is roughly identical to RfA. Commissioners would be elected, and would represent the community's will. Their votes would be equivalent to the votes of those who voted for them, in line with the principle of the social contract. Your concerns are unfounded. RGloucester — ☎ 02:50, 1 December 2014 (UTC)
    Your claim that the proposed process is "roughly identical to RfA" is preposterous. The WMF might deem it a satisfactory alternative, of course. Are you suggesting that there's no need to inquire? —David Levy 03:41, 1 December 2014 (UTC)
    The only difference would be that commissioners would cast votes on candidates for adminship on behalf of the community. There is no difference, because the commissioners would be elected by that community. It is merely a form of delegation and representation. To be honest, I hardly think that it matters what they think. What's good governance is good governance, regardless RGloucester — ☎ 13:40, 1 December 2014 (UTC)
    The only difference would be that commissioners would cast votes on candidates for adminship on behalf of the community.
    Other than that, Mrs. Lincoln, how was the play? (My apologies for not knowing a British equivalent.)
    It's a fundamental difference. That doesn't make it bad, but I'm taken aback by your continued assertion that it's inconsequential.
    And it isn't "the only difference". You advocate the creation of a representative democracy, wherein the community elects "commissioners" to actively recruit candidates and appoint administrators via simple majority votes. This is very different – in multiple key respects – from RfA, wherein the community engages in open discussion and the bureaucrats gauge consensus.
    There is no difference, because the commissioners would be elected by that community.
    Irrespective of which system is better, how can you possibly believe that "there is no difference"?
    To be honest, I hardly think that it matters what they think.
    It doesn't matter what the Wikimedia Foundation thinks about this? Is that actually what you're saying? —David Levy 08:31, 2 December 2014 (UTC)

Support (alternative to RfA)

  1. John Carter (talk) 01:02, 26 November 2014 (UTC) - This proposal has a lot of the strengths of one of the other proposals above regarding possible "automatic" appointment of admins while also having the one thing I think that proposal lacked, which is some sort of body to see that there is some sort of review of candidates.
  2. It's time that we have some sort of change. Let's not be fooled into thinking that "there is no problem, after all" because of the recently successful RfAs. In fact, we lost a great vandal fighter as a result of RfA just a few days ago. --Biblioworm 01:09, 26 November 2014 (UTC)
    Yes, we lost a prolific vandal fighter (at least temporarily) but that RfA is not a good example of the RfA process failing. The user's reaction to their RfA further underscores the concerns raised by the opposes. The user should not be an admin unless change occurs. We may occasionally lose editors due to failed RfAs like this but administrators lacking judgment and tact can ultimately do more harm to Wikipedia's reputation than their contributions are worth. It seems likely the user may have had already contributed to good faith editors leaving the project merely as an editor. So please, don't use that RfA as the process not working. Jason Quinn (talk) 19:37, 27 November 2014 (UTC)
  3. Support as proposer – This proposal will allow RfA to continue. It will not, as they say, throw the baby out with the bathwater. It will allow the community to trial an alternative method of appointing administrators. It will remove the toxicity of RfA from the equation, allowing for candidates who are more technocratic, but less able to handle the political requirements of RfA. Commissioners will be representatives of the community who will work to solve the problems we face, least amongst them the problems of having good administrators. This proposal, as far as I can see, is flexible and worth a shot. We've seen this debate go on for years, and now we have a chance to do something about RfA reform. We need this Commission. RGloucester — ☎ 02:21, 26 November 2014 (UTC)
    This proposal will not "remove the toxicity of RfA from the equation" - it will create new and unpleasant drama. If a user is unsuited to being elected via RfA, but is then elected by the committee, the committee which elected that user will face questions, some of which will be very hostile. This will happen. And it will be very unpleasant for all concerned. This is not a solution, it's the creation of a new (and possibly bigger) problem. If a user is so uncontroversial that nobody would question their appointment, then they would sail through a RfA, and so would not need a committee to elect them. SilkTork ✔Tea time 18:54, 27 November 2014 (UTC)
    OK, but WHAT WOULD remove the toxicity of the RfA process? We can't change human nature or the personalities of the individuals in the WP community. Without an RfA alternative, how can any progress be made? --Scalhotrod (Talk) ☮ღ☺ 20:39, 27 November 2014 (UTC)
    Um, some very good contributors have not "sailed through RfA". In fact, some have had very difficult RfAs. The fact of the matter is that RfA is mob rule, and as the name implies, mobs are not very sensible. —Biblioworm 19:03, 27 November 2014 (UTC)
  4. Support - I helped with drafting the proposal, BTW. We will have a lot more good administrators if all they have to do is ask. Oiyarbepsy (talk) 03:33, 26 November 2014 (UTC)
  5. Support. This will allow good candidates to become admins without the stress and hostility of an RfA, and should result in many more good editors applying for the position, and in many more good admins. Bad candidates would still not get the position, and there would finally be a way to desysop existing admins without starting an ArbCom case. If editors are worried about the standards that ASC would apply, they can always run for the committee themselves. — Mr. Stradivarius ♪ talk ♪ 05:34, 26 November 2014 (UTC)
  6. Tentative support I like the concept, though I do have concerns with the details, but they can get fixed later. See my comments above for some detailed thoughts. For example, I do think that the community should have more of a say in the ground rules of such a board and worry that it will find itself bogged down on discussions of perfectly acceptable though less than perfect candidates. I feel a more vetted more streamlined process might better serve the project in the long term even if it rejects some okay would-be admins to the RfA process or a future attempt. PaleAqua (talk) 05:50, 26 November 2014 (UTC)
  7. Tentative support but only if this ASC isn't filled with the same old boys club who make RFA so toxic in the first place. Community choice should be an aspect but the community I feel is idiotic and holds absurd standards as who and who cannot be an admin and if anything I want to see that sort of self-selecting removed from the equation, I'm not sure if this new body would do that (and heck knows there'll be some bleating from those who make RFA a hellhole citing a denial of their opinions for objection) but enough with shoving people in front of a board of peers who already failed the candidate before they walked through the door.tutterMouse (talk) 09:53, 26 November 2014 (UTC)

  8. As others have stated, mob rule does not work; it scuttles RfA, ANI, RFC/U (which is probably soon to be disbanded), and partly also Arbcom cases. Apart from the trolls, peanuts, and regular system detractors who participate on RfA, there is a huge number of one-off voters and I am curious to know what part of the Wiki woodwork they come out of to place a vote on RfA. I am fairly certain that on some RfA a certain amount of canvassing takes place. Anyone who wittingly allows such canvassing is probably not to be trusted to be an admin while anyone who actively canvasses for their RfA (even offline where don’t catch it) is corrupt from the start and should never be a sysop.

    Genuine candidates who have no skellies in their closets should not fear the current system and if they have kept their noses clean through their Wiki careers they will almost certainly pass, with little drama, and with flying colours. Whatever the section however, there are always silly votes that should not be counted. Comments such as “Seems OK to me’’ equate to: ‘’I don’t know the guy. I haven’t done any research, but his user name sound right.’’ I won’t go into providing examples of some of the utterly ridiculous oppose statements, but a completely drama-free RfA is an extremely rare occurrence indeed. Although WP:RFA2011 did not realise any physical reforms, it left behind an enormous legacy of research which clearly identified the main single problem with RfA. The individual regular ‘elements’ of that problem have got the message, and a couple of recent RfA have shown that the community is now going to be bold and do something active about unruly or inappropriate behaviour there.

    I therefore no longer believe RfA is the broken place I (and Jimbo Wales) claimed it to be 4 years ago. However, I see no reason why this current proposal should not be tested before the community, so I SUPPORT it in principle, with just a few minor tweaks to be made later (e.g. I year terms, No limit to the number of terms; the WMF will not allow non admins to view deleted content), and it’s now up to the broader community to voice their opinion. --Kudpung กุดผึ้ง (talk) 10:05, 26 November 2014 (UTC)

  9. Support Good candidates will get through in any case; but present-day RfAs generate a lot more heat than light, and draw us away from more useful work. Voters can always be characterised as a mob by the losing side, justified or not. It doesn't bother me now if User:Xaelrukfhpaw gets rollback rights without my say-so; well same goes for the remaining admin tools. (Please clarify re elections: 3+4=13??): Noyster (talk), 10:59, 26 November 2014 (UTC)
    That was an error left over from an earlier draft. It has been fixed. RGloucester — ☎ 13:41, 26 November 2014 (UTC)
  10. Support - The community has simply grown too large and impersonal to expect that any discussion involving 100+ people will be civil, rational, and drama-free. Delegating this task to a smaller, elected committee may increase some bureaucracy, but the resulting reduction in drama and incivility and making adminship even a slightly-less-big deal makes it a net positive IMO. Mr.Z-man 16:09, 26 November 2014 (UTC)
  11. Support.—S Marshall T/C 16:29, 26 November 2014 (UTC)
  12. There's room for discussion about the particulars of the committee's composition, but after the recent Andrevan fiasco, this proposal has serious merit. Townlake (talk) 16:33, 26 November 2014 (UTC)
  13. Support Please don't oppose this over small details like the composition requirement, if you support the proposal otherwise. The details can be changed later. The added bureaucracy of this is a small price to pay for potentially fixing so much that is wrong with the current systems. And if it doesn't work out, I'll be right there with you getting it disbanded. It's absolutely worth a try. We can't keep doing the same thing and refusing to even try something different. Gigs (talk) 17:46, 26 November 2014 (UTC)
    "The definition of insanity is doing the same thing over and over and expecting different results." -Albert Einstein --Biblioworm 18:18, 26 November 2014 (UTC)
  14. Weak support - I had this in the neutral section, but on the balance I guess I support this. Wikipedia is not a democracy, so comparisons to democratic models are basically irrelevant. However, to put this in a democratic frame, Administrators are effectively our police force, and it makes sense to me that they should be qualified rather than elected, and having an elected body evaluate qualifications makes sense in that democratic framework. I see strengths and weaknesses to this proposal. I would prefer if this process were to replace RfA, rather than run parallel, otherwise we will have two classes of admins, those appointed by Commissioners and those elected by the community, subject to different disciplinary processes, and that's bad. In order to work, all admins (even those who endured RfA) must be subject to reviews by ASC. And that's going to be controversial, but in general yeah, it's a good idea for admins to be subject to a common disciplinary process. I'd like to see more in the proposal about the election of Commissioners, in particular I'd like to see a process for the community to express loss of confidence in the Commission, which would trigger a new election. I won't support removing individual Commissioners - either the Commission works as a whole or it doesn't, and if it doesn't then it should be wholly replaced. I'm also concerned that this won't really solve the "no big deal" issue - adminship will be no big deal but we're just shifting the "big deal" onto election to the Commission. Then again, maybe that should be a big deal. This is a step in the right direction, anyway. Ivanvector (talk) 18:34, 26 November 2014 (UTC)
    You are abusing the "not a democracy" policy with this argument. Wikipedia is not a democracy, but our governance and core values are democratic. Specifically a form of deliberative democracy. So yes comparisons with democratic systems are absolutely relevant when someone is trying to highjack the system by turning it into technocratic authoritarianism. Also you seem not to have noticed that we are also not a bureaucracy.User:Maunus ·ʍaunus·snunɐw· 18:48, 26 November 2014 (UTC)
    You seem to have not noticed that we are a bureaucracy, in many ways. Some level of bureaucracy is necessary to administer and maintain a project of this magnitude. What makes Wikipedia somewhat unique is that all of our bureaucracy and administrative process has evolved from community consensus over time, and it continues to evolve. At times that looks like this or that form of existing system, because sometimes that's what's best to serve the community's purposes. Sometimes "consensus" means we come to a community decision that a certain subset of people are best equipped to deal with a particular problem. That looks like bureaucracy, and it is, but that's not inherently bad. We can't always leave every little routine task up to the will of a community of millions, and promotion/demotion of administrators should be much more routine than it is. Ivanvector (talk) 20:36, 26 November 2014 (UTC)
  15. Cautious support, on a trial basis only. My initial reaction to seeing this proposal was to oppose strongly, but on thinking about it, I think it is worth a try, as a sort of experiment. I'm uncomfortable with taking the process out of direct community control, especially because the community may discover information about a candidate that a committee might have overlooked, but I also think that the community will have exerted as much control over the composition of the proposed committee as they currently do over ArbCom. I think we should implement it for one year only, and require a followup RfC to determine whether the community will agree to continuing it beyond that. --Tryptofish (talk) 22:39, 26 November 2014 (UTC)
    • Comment: If it isn't explicitly stated in the proposal already, I haven't checked, I think it would be a good idea if perhaps it had a sort of suggestion or pending period before confirmation built in, between the time of a potential candidate being suggested and the time of actual confirmation, which would allow other editors to contact the committee with their concerns, and possibly discuss them, publicly or privately, at some length if needed, the concerns raised. FWIW, and I think some kind of clear statement here might be useful, I myself hope that the committee winds up being one which in a sense is predisposed to approve pretty much all candidates who don't obviously disqualify. I know that would of course be dependent on the personalities of those who actually get on the committee, of course, but still think some clarification might be useful. John Carter (talk) 22:47, 26 November 2014 (UTC)
    Please read the full proposal, specifically the implementation section. This proposal is only for a trial period, to be followed by a new RfC. RGloucester — ☎ 22:56, 26 November 2014 (UTC)
    Yes, I did read that. What I said goes a little further in terms of making it a trial only. --Tryptofish (talk) 16:12, 27 November 2014 (UTC)
  16. Conditional Support only and only as a supplementary processes and not for replacing RFA in foreseeable future. Currently the lede states it's for supplementing or replacing it. If it is clearer that a later consensus would be needed to discuss a possible replacement and there's no implication of replacement without another discussion at a later stage, I would change to 'support'. --lTopGunl (talk) 23:22, 26 November 2014 (UTC)
    Please read the implementation section. RGloucester — ☎ 23:24, 26 November 2014 (UTC)
    Thanks... the lede confused me. --lTopGunl (talk) 23:28, 26 November 2014 (UTC)
  17. Strong Support While the idea of additional bureaucracy is difficult, this would help address a number of backlog problems. I'd actually support this completely replacing the Admin election process. DocumentError (talk) 09:15, 27 November 2014 (UTC)
  18. Support There needs to be an alternative to the bear-pit of RfA. Bazj (talk) 13:30, 27 November 2014 (UTC)
  19. Weak support I don't think it's the best idea in the world but I'm up for trying something new. The proposed implementation plan makes it straightforward to revert to what we have now if it doesn't turn out well. WaggersTALK 13:32, 27 November 2014 (UTC)
  20. Support There needs to be an alternative for the battleground we call RfA. --AmaryllisGardener talk 14:21, 27 November 2014 (UTC)
  21. Support Hawkeye7 (talk) 20:04, 27 November 2014 (UTC)
  22. Support - Based on my impression of the RfA process, that its often (but not always) a tedious, contentious, and often demoralizing process, I would welcome an alternative. Just from my observations and limited involvement with RfAs, the process comes across like some sort of U.S. Senate-style confirmation hearing where the subject is publicly pushed and/or scrutinized in every possible way and by every detail. --Scalhotrod (Talk) ☮ღ☺ 20:29, 27 November 2014 (UTC)
  23. Temporary Support: There are many subtleties and implications which daunt my imagination, so it is too hard to determine how this will work, let alone decide whether it is an improvement or not. Let's just try it for a reasonable period (3 months?) and see how well it works. If it doesn't, end it. If it works great, leave it alone. If it sort of works, decide in a month or so how it might be tweaked. —EncMstr (talk) 20:47, 27 November 2014 (UTC)
  24. Strong Support:

    (a) RfA is seriously broken; (b) the only people who pass the process are those who've carefully never taken a stand, never uttered a cross word and have left no handles for anyone to grasp, and thus robs Wikipedia of many talented, able, passionate would-be admins; (c) RfA gives more weight to knee-jerk, thoughtless responses, because after all it only takes five seconds to type "Oppose: He's a deletionist who'll destroy Wikipedia" or "Support: Doesn't strike me as out to get the encyclopedia;" (d) RfA damages Wikipedia because it deters people from running and has provoked once-able editors to quit in anger over their treatment; and (e) RfA is the only area on Wikipedia where it's permissible to canvass against someone. RfA needs to be taken out of the community's hands.

    I wrote the foregoing six years ago, in a RfA review that like many other attempts at reform went nowhere. Things haven't changed, and it's one of the few areas of Wikipedia run by popularity contest head counts. With the current process, while I'd love to see a bureaucrat say "I don't care that she only got 55%, this is a worthy, talented, qualified candidate that got steamrolled by a bunch of nitpicking and irrelevancies," it isn't going to happen, and it never has happened. I'd support damn near any scheme to take this out of the community's hands, before the day comes where the admins are mostly gone. Ravenswing 22:36, 27 November 2014 (UTC)
    Couldn't have said it better myself. —Biblioworm 01:21, 28 November 2014 (UTC)
  25. Support: I adore the idea of selection by experts. I've seen its efficiency in the form of the tenure committee. RfA allows everyone, including a recent signup, to ruin the nomination of a potentially good admin or give support to an otherwise unworthy candidate. This isn't fair. A well-known objection to election by majority is that it requires fame, not competence. WikiGnomes have no chance of succeeding in an RfA because success in RfA chiefly demands having a lot of good friends. Best regards, Codename Lisa (talk) 23:59, 27 November 2014 (UTC)
  26. Support: There is clearly a problem with the current process. Many good editors would step up if the process was not similar to an inquisition based on experiences with those that follow this side of Wikipedia (as mentioned above FAME). The problem is that being an admin is no big deal.....and for the most part only admins believe this. Thus the average voter at an RfA is more concerned with what might go wrong over the good that could come with give extra tools (that is all amdminship is more tools) to great editors. I have said this before as have others...just need to appoint admins with limited tools at first (levels of administration)....thus have a 3 or 4 levels of tools....as an admin gains experience and show they are mature enough to handle the new tools they will get more and more tools. -- Moxy (talk) 02:38, 28 November 2014 (UTC)
  27. Tentative support per Kudupung. Jim Carter 12:11, 28 November 2014 (UTC)
  28. Support; doing something to RfA is long overdue. If this works, great; if not we can always return to the broken process we have today. Let's just be bold and try it. Bjelleklang - talk 22:04, 28 November 2014 (UTC)
  29. Support FeydHuxtable (talk) 18:19, 29 November 2014 (UTC)
  30. Support It's been a long time since I was a regular voter at RfA, but I've kept tabs on it and feel that this alternative proposal has merits. I think a glaring negative of the RfA process is that it is subject to the whims of whoever shows up. If you look at any subset of RfA's from specific points in time, those adjacent to each other all have similar themes and points of emphasis driven by the active voters of the day. With a fixed commission, you'll still have trending patterns driven by the membership, but I think there would still be a greater degree of standardization and accountability in the process. Another point in favor of the commission is that it does not immediately seek to eliminate RfA, and I think it's worth having both paths to the mop open. The key here is that the goal is not to have a smaller pool of admins, but is in fact to grow the pool of admins. The more of us there are, the more open the project is. With a broader pool of trusted editors gaining access to the tool, the admin role regains (or finally gains?) the "no big deal" aspect that it was intended to carry all along. Whether you're someone who just likes to make cleanup edits, or a powerhouse creator of articles, you should be welcome to the extra functionality that admin rights provide so that you can help contribute in more ways, if it so interests you. Will the occasional less-than-constructive individual get through? Yes, but to echo Moxy's comments, the Orwellian fear of this hypothetical is one of many straw man obstacles that either derails RfA's, or that prevents many qualified editors from even bothering with requesting the tools in the first place. Hiberniantears (talk) 19:41, 29 November 2014 (UTC)
  31. Support It is time to do something about the current RfA process, which is more about hazing and attacking than it is about getting worthy admins. Eeekster (talk) 22:16, 29 November 2014 (UTC)
  32. Support on trial basis. RfAs may be stressful for some, even though this process shows community support. In order so that we don't elect unworthy admins, however, we should then only have bureaucrats or really experienced administrators on this Administrative Standards Commission. Epicgenius (talk) 02:39, 30 November 2014 (UTC)
    The proposal calls for six seats open to administrators, six seats open to non-administrators, and one seat open to either. —David Levy 05:03, 30 November 2014 (UTC)
    That means that 46% of those deciding who is an admin are admins. Does the community really want to give up its authority over who becomes and admin to a group of 13 people who are almost half admins? Being an admin is nothing special and it should not give them the power of a super vote or to appoint people they think will be good admins. Chillum 17:59, 30 November 2014 (UTC)
    I agree, and the same goes for not being an admin. The separation of admins and non-admins into distinct classes with separate "representation" is one of this proposal's many fundamental flaws. —David Levy 22:35, 30 November 2014 (UTC)
  33. Support, essentially agree with statement by John Carter, above. Cheers, — Cirt (talk) 02:41, 30 November 2014 (UTC)
  34. Tentative support. Before I actually read the proposal I have to say that my hackles were raised. Another layer of bureaucracy. Never! But then I read the proposal it's not bad. Worth doing on a trial basis at least. I do think the provision on removing administrators needs to be fattened up substantially. Also the ASC's deliberations should be entirely transparent. Coretheapple (talk) 20:24, 30 November 2014 (UTC)
  35. Support on a trial basis only - See also my struck out oppose below. After sleeping on the idea a bit and looking back at the proposal again, I think this could be worth trying out. I don't think it will ever be able to replace RFA, but I do think it has the potential to supplement it, and a trial is necessary here so the proposal can properly be tested. We'll never know how it works unless we try, and it has the potential to be a good alternative to RFA for those who wish to try it. demize (t · c) 00:59, 1 December 2014 (UTC)
  36. Moral Support - it's not going to pass, but trying to do something to RfA is very important. I don't like the focus on technophilic users in the proposal -- they are underserved in RfA understandably, but not the only user types. WP needs more leadership and more boldness, so I like trying to try something new. -- Michael Scott Cuthbert (talk) 08:44, 1 December 2014 (UTC)
  37. Support - I wonder how many current admins would voluntarily go through the RfA process again. The vetting process is an absolutely horrible experience for tools which aren't supposed to be a huge deal. — BranStark (talk) 13:39, 1 December 2014 (UTC)
  38. Supporting Appointment is fair. New England Cop (talk) 19:49, 1 December 2014 (UTC)
  39. Support - If being an admin is no big deal, and if we would like to have more (or at least a sustainable number of) competent admins, then it seems like a bad idea to require them to be politicians as well. Ravenswing makes some good points above. I don't really see any harm this proposal could cause, since it is not immediately replacing the current system anyway. I'm not so sure about the idea of having a fixed number of admins and fixed number of non-admins.. but, on the other hand, I don't really have a better suggestion. I think this would be worth a try. Mark M (talk) 09:37, 2 December 2014 (UTC)
    • "... it seems like a bad idea to require them to be politicians as well." A telling turn of phrase, and one I wish I'd thought of years ago. While of course this effort is as doomed as all the other ones, it's worth saying. Ravenswing 14:57, 2 December 2014 (UTC)
  40. Support - The current process is hopelessly broken in that an ever decreasing number of editors will subject themselves to the abuse. Even if I wanted to be an admin, I would never put myself, even if asked, thru the current process. VMS Mosaic (talk) 10:25, 2 December 2014 (UTC)
  41. Support something like this, but not with these particular details, e.g., about how many seats are reserved for admins vs non-admins (in that example, I think the community should be able to elect whomever they want). WhatamIdoing (talk) 19:59, 2 December 2014 (UTC)
  42. Support. Protonk (talk) 19:28, 3 December 2014 (UTC)
  43. Support per Ravenswing's comments above. "... it seems like a bad idea to require them to be politicians as well." Tony Tan98 · talk 14:31, 17 December 2014 (UTC)

Oppose (alternative to RfA)

  1. The most extremely strong oppose anyone has ever opposed, which can never be over opposed by anyone ever The last thing we need is another clique of oligarchs, or commissaries or what ever you want to call them. What we need is more and better admins. And the realization that the tools are no big deal.User:Maunus ·ʍaunus·snunɐw· 02:29, 26 November 2014 (UTC)
  2. Oppose as above. Yet another proposal which would foolishly put too much power into a small clique of officials, complete with even more of the bureaucracy everyone already hates. Seriously, take 30 seconds and ask yourself, honestly, what sort of person would seek to get elected to something called the "Administrative Standards Commission". Really, really think about it. Then, take 30 more seconds and consider whether giving more power to those people is a good idea. If you think that sounds just swell, congratulations, you're officially part of the problem. Andrew Lenahan - Starblind 03:51, 26 November 2014 (UTC)
    You would probably need to be crazy to want to run for ASC. But then, at the moment, the same thing could easily be said for RfA. We should be encouraging good editors to become admins, and the current system is having the opposite effect. — Mr. Stradivarius ♪ talk ♪ 05:46, 26 November 2014 (UTC)
  3. Oppose. There isn't much to say here that hasn't already been said. Creating a middleman - regardless of whether it replaces RfA or not - sets a dangerous precedent. ProtossPylon 03:55, 26 November 2014 (UTC)
    What "precedent" is that? They are not a "middle man". They would be a group of people elected by the community to carry out an important function for this project's survival. RGloucester — ☎ 04:01, 26 November 2014 (UTC)
  4. Oppose Creating admins requires community approval, and as a community member I do not want to cede my approval to a commissioner. — xaosflux Talk 04:15, 26 November 2014 (UTC)
    Additionally, I oppose lowering the bar for creating and removing administrators to 54%. — xaosflux Talk 04:21, 26 November 2014 (UTC)
  5. Oppose per Andrew. RFA needs major overhauling, but replacement by a middleman would be worse. "Middleman": in this context, a group standing between the community and the admin-choosing process. Also known as "republic" versus the current "democracy". We've previously had a system with a republican setup, where regular editors chose people with the power to make decisions: see how we dealt with it by reading through Wikipedia:Miscellany for deletion/Wikipedia:Esperanza in depth. Nyttend (talk) 04:18, 26 November 2014 (UTC)
    I think anyone who reads both this and the Esperanza page in depth would immediately realize the blatantly obvious differences. This would be more like the Arbitration Committee. Oiyarbepsy (talk) 05:08, 26 November 2014 (UTC)
    I was bored this morning and wasted most of an hour reading through the Esperanza MFD, the deletion reviews, etc., and this looks very much like the depictions of the Advisory Council in the MFD that I linked. We need to remind bureaucrats to start doing like we administrators tend to do in discussions and ignore votes that conflict with policies (WP:DEAL, here), ignoring the people who object on grounds such as "Not enough FAs" that don't speak to whether the person is likely to abuse the tools. Nyttend (talk) 06:35, 26 November 2014 (UTC)
    Exactly. One need only read RfA discussions from years ago (when the process functioned as intended) to see how these inexplicable demands have contributed to the toxic atmosphere. —David Levy 07:12, 26 November 2014 (UTC)
    Lol. What on earth makes you believe that RfA was functioning as intended. It hasnt been functioning for the past 5 years at least.User:Maunus ·ʍaunus·snunɐw· 18:02, 26 November 2014 (UTC)
    Perhaps you overlooked the words "from years ago". —David Levy 19:38, 26 November 2014 (UTC)
    I've now taken the time to read all this Esperanza rubbish, and I can frankly say that it bears no relation to the ASC I've proposed. That body sounds like it was some kind of odd social organisation with a sprawling membership and a propensity for self-promotion. This body would not be like that. There would no membership, only commissioners. They'd would be like arbitrators, not like these so-called "Esperantos", or whatever they were called. Their only function would be to work on appointing administrators. No "social" elements would be involved. Your asking of bureaucrats to "ignore votes" seems like an acknowledgement that the overly democratic nature of RfA is the problem. Given this, rather than entering into subjective "ignoring" of people, why don't allow the community to elect the ASC to vet candidates in line with community-accepted principles? As I said below, the well is already poisoned. The genie is out of the bottle. There is no going back to how RfA may have been "years ago". The culture of Wikipedia simply won't allow us to go back in time, in such a way. We need to move forward, not backward. This proposal allows us to do that. RGloucester — ☎ 16:55, 26 November 2014 (UTC)
    If the crats thought they had the freedom to ignore such votes, they'd be doing it already. RGloucester is right, that would basically turn them into what this ASC will be, except without the consent of the community. An overall worse idea than just approving this and going forward with people who are explicitly empowered by the community to have such latitude. Gigs (talk) 17:54, 26 November 2014 (UTC)
    RfA is intended to function as a consensus-building discussion, not a simple majority vote. The bureaucrats are supposed to weigh the comments made, not tally the votes and call it a day. The problem is that we lack a clear set of criteria regarding which rationales are valid and invalid (which the bureaucrats don't feel empowered to invent). Yes, replacing RfA with the proposed ASC would effectively assign "such latitude" to those elected. In my view, that would be a very bad thing – and not "basically" what Nyttend described. No one here advocates that the bureaucrats substitute their personal judgement for that of the community, which is exactly the role that the proposed ASC would assume. Instead of bureaucrats examining a community evaluation and applying a defined set of standards to determine its outcome, an elite group of editors would decide on the community's behalf. You're entitled to prefer the latter, but please don't equate the two. —David Levy 19:38, 26 November 2014 (UTC)
  6. Oppose forgive my vanity, but I prefer having a say (tiny as it is) in who becomes an administrator & who doesn't. GoodDay (talk) 05:27, 26 November 2014 (UTC)
  7. Oppose. A bad idea with even worse execution. (No offense intended toward the editors behind it, by the way. I'm trying to word this as delicately as possible.) We have a process that worked well in the past, and it can work well again. To accomplish this, we need less bureaucracy, not more. —David Levy 07:12, 26 November 2014 (UTC)
    I think we need to accept that the well has been poisoned. RGloucester — ☎ 13:46, 26 November 2014 (UTC)
    Replacing RfC with the proposed ASC would be like dynamiting the old well and constructing a new one in exactly the same location. Until we eliminate the actual poison, it will continue to rise to the service.
    You propose that we replace toxic adminship requests with toxic "elections" to an elite body of editors in charge of selecting administrators on the community's behalf. I'm baffled as to how this is supposed to address the actual problem. If anything, it might even amplify it; because the ASC seats are guaranteed to be filled, the nonsense that currently leads to failed requests at RfC would instead skew the results of these "elections". The same pool of users currently denying trustworthy editors adminship would be responsible for voting in a group of editors with carte blanche (for a time, at least) to grant or deny adminship to whomever they please. —David Levy 19:38, 26 November 2014 (UTC)
    The proposal is not to replace RfA, but to supplement it. Are ArbCom elections "toxic"? Does ArbCom exist as an "elite body of editors"? RGloucester — ☎ 20:39, 26 November 2014 (UTC)
    Eh....yes and yes?User:Maunus ·ʍaunus·snunɐw· 20:50, 26 November 2014 (UTC)
    I'm sorry you feel that way. There is an ArbCom election going right now, and I haven't seen any "toxicity" anywhere. I've never seen arbitrators acting as an "elite body of editors". They seem to relatively demure. I fear that such liberal views as yours are simply not reconcilable with reality. RGloucester — ☎ 20:57, 26 November 2014 (UTC)
    I dont think you are in a position to make that judgment, it doesnt seem to me that "reality" is a place you frequent a lot.User:Maunus ·ʍaunus·snunɐw· 21:38, 26 November 2014 (UTC)
    Manus, I don't like this proposal either, but the spirit you show of "attacking the person, not the problem" is 99% of the problem with RfA and every other part of Wikipedia that is broken. It discourages consensus, and disengages everyone but trolls and people who love a good fight. That spirit, by far, is what I LOATHE most about Wikipedia and is the reason why I left for several years; your comment above exemplifies it.--Esprit15d • talk • contribs 04:55, 2 December 2014 (UTC)
    The proposal is not to replace RfA, but to supplement it.
    You've conveyed quite clearly that you want to replace RfA (and the proposal explicitly calls for consideration of this). But that's a tangential point, as I'm addressing the premise that the new process would somehow be immune to the "poison" affecting the old one.
    Are ArbCom elections "toxic"?
    Part of the problem is your apparent failure to recognize that material distinctions exist between the objective of RfA and that of an ArbCom election. I do believe that the latter is subject to some degree of toxicity, but the specific "poison" contaminating RfA isn't present there. Conversely, given that the ultimate goal (recruiting new administrators) would remain the same, I see no reason to believe that it wouldn't remain in force in the proposed ASC process. It would simply impact the election of "commissioners" instead of interfering with the promotion of administrators.
    Does ArbCom exist as an "elite body of editors"?
    In certain instances, its members have behaved as such. (That's a separate issue, of course.) But again, you're missing the point that the underlying functions differ materially. The ArbCom exists "primarily for serious conduct disputes the community has been unable to resolve", not as a substitute for community decision-making. It's when they veer off course in that direction that they start to resemble "an elite body". —David Levy 22:10, 26 November 2014 (UTC)
  8. Oppose The system we have works well. Chris Troutman (talk) 15:52, 26 November 2014 (UTC)
  9. Oppose. Tweaking the existing RfA process would be a much better approach than creating a bureaucracy that would most likely represent the views of the community poorly. --Michig (talk) 16:56, 26 November 2014 (UTC)
  10. Oppose An administrator should have the consent of the community, not some committee. What happens when we don't like how the committee is acting? This is just moving power around and diluting the communities direct authority over who is an admin. It is a shell game and like any shell game you cannot win. Chillum 16:59, 26 November 2014 (UTC)
    These administrators would have the consent of the community, because the community would be entrusting the commission to appoint them through elections. That's how it works in the tangible world. No one is concerned about the "consent" of a state's populace when someone is appointed to work as functionary in the civil service. If you don't like how the commission behaves, elect different members. RGloucester — ☎ 17:13, 26 November 2014 (UTC)
    You are talking about second hand consent. Once selected they can just choose whoever they want. Your analogy to the state does not fill me with confidence as they don't have a stellar track record. Chillum 17:19, 26 November 2014 (UTC)
    Social contract? RGloucester — ☎ 17:22, 26 November 2014 (UTC)
    With respect that is at best innocent of you and at worst naive. People are going to act like people. Chillum 17:28, 26 November 2014 (UTC)
    Yes, and I believe that when people act like people, they act for the good of the collective. RGloucester — ☎ 20:29, 26 November 2014 (UTC)
    Acting 'for the good of the collective' is only done by idealised people; real people naturally act for their individual good. That is what 'acting like people' essentially boils down to, and it is common to other species as well because such an instinct is the most conducive to survival. Attempts to create a collective and to force people to act for its good rather than their own are often misguided and always flawed, as demonstrated by Ayn Rand novels and the Soviet Union. That is not to say that selfishness is the highest good and collectives are evil, but rather that one works and the other doesn't. ekips39 05:35, 27 November 2014 (UTC)
    I disagree. I also disagree with the idea that there is any such thing as "instinct". Sadly, I fear you are a rationalist, and I shan't engage in a diatribe that has little relevance to the topic at hand. RGloucester — ☎ 06:30, 27 November 2014 (UTC)
    Well clearly there is such a thing as instinct. If your position is based on the idea that humans do not act off of instinct and that instinct does not exist then I now see the flaw in your reasoning. For example describing an opposing point of view as a diatribe is often an instinctual response to your ideas being attacked.

    First denying instinct and then suggesting rationalism is somehow wrong does not leave much left. What is left after instinct and reason are removed? Chillum 18:29, 28 November 2014 (UTC)

    Actually, he seems to have used 'diatribe' to refer to the comments he wasn't going to make, not to what I said. ekips39 04:04, 29 November 2014 (UTC)
  11. Oppose - I think implementing this would just be 'moving the mess'. The root cause of problems with RfA are people - not all those people who contribute there, not even most, but enough to cause things to degenerate into madness far too often. We need more robust guidelines for contributing to an RfA (e.g. what sort of arguments are substantive and should 'count', clearer lines on what is and is not 'badgering', etc.) and stronger moderation of RfAs based on these. We do not need more process and indirection; Wikipedia is not Vogsphere. Reticulated Spline (t • c) 18:29, 26 November 2014 (UTC)
  12. Oppose, sorry. In my view, the last thing we need, with our article space dying due to lack of attention, is another layer of project-space bureaucracy, least of which a layer that will remove the direct say that editors have in the promotion of administrators. I also agree with Andrew Lenahan and GoodDay. --Mkativerata (talk) 20:03, 26 November 2014 (UTC)
  13. Regretful oppose. Great idea, but I must oppose for the following obvious reason: Sometimes, an RFA can be derailed by one detailed "oppose" vote, and the same thing could very well happen if the editor "running for administrator" has interacted with someone from the proposed committee in a way that would cause them to vehemently oppose the candidate. Rather than having a pool of hundreds who could prove the opposer wrong, the "candidate" would be at the mercy of the other representatives on the committee agreeing or disagreeing with the opposing committee member's opinion, giving the "candidate" less of a chance to recover from the "oppose vote". Steel1943 (talk) 23:39, 26 November 2014 (UTC)
    Please note the implementation section, which people seem to not have read. This process would be a parallel to RfA, at the start. If someone has a problem with ASC, they can go to RfA, or vice-versa. RGloucester — ☎ 02:40, 27 November 2014 (UTC)
    If that is the case, then my worry would be that an RFA oppose vote would be "per the ASC discussion" or vice versa. Two forums that attempt to accomplish the same outcome almost always interfere with each other's purpose, even if that is not how it was intended to be designed. Steel1943 (talk) 05:39, 27 November 2014 (UTC)
    There's that too; but in any case, the prospect of having two forums for the same purpose does not negate the value of objections to one of them. ekips39 14:56, 27 November 2014 (UTC)
  14. Oppose I'm not as intimately familiar with RFA as some of the people here undoubtedly are, but I have a reasonably clear notion of what the alleged problem is. I basically agree with Reticulated Spline: What we need is a more well-defined set of standards to judge candidates by, not a more limited set of people doing it. I believe that having the entire community decide who gets to be an admin helps to counter the risk of having a narrow, biased set of views on the subject. As I point out above, people naturally act in their own interest; with enough different people acting on enough different interests, that effect is more likely to be neutralised. Clear criteria for !votes (which I plan to elaborate on at some point) seems a better way to solve the problem of insubstantial arguments. ekips39 05:35, 27 November 2014 (UTC)
  15. Oppose - Per all of above. Plus, I'll not cede my review process to a committee of six. Those sis may not even heard of me when I submit my review and then how on earth they can come to know about my editing character? Will they go through all my edits (For instance, if it Justin, with over 1.4 million edits) and then analyse my editing character? RfA should always be a community opinion, not just an opinion of six users. They may not select a person who would get 100+ supports in RfA, because enmity can have its probability for a committee at maximum, but minimum in public process. --The Herald 12:50, 27 November 2014 (UTC)
    @The Herald: Actually, the proposed number of the committee is 13: six admins, six non-admins, and one position for either an admin or non-admin. These numbers could be changed after further discussion. Also, there would likely be a space for non-committee members to submit evidence about admin candidates, so there would still be a place for community review, although the final decision would be taken by the committee. — Mr. Stradivarius ♪ talk ♪ 13:11, 27 November 2014 (UTC)
    If community review remains a component (and I agree that it should, so I'm not finding fault with the idea), the elimination of "drama" (on which some of the above support is based) is removed from the equation. What does that leave us with? Instead of a system in which the aforementioned community review is analyzed by one or more bureaucrats to gauge consensus, we'll have one in which thirteen "commissioners" receive essentially the same input ("drama" included) and are free to heed or disregard it and decide whatever they please. How, exactly, is that an improvement? —David Levy 13:44, 27 November 2014 (UTC)
    It would put the focus on facts, rather than on percentages. I'm thinking of a format similar to, e.g., ArbCom clarifications and amendments, where each user can comment in their own "Statement by UserX" section. The current RfA discussion structure has a tendency to make editors worried about the number of opposes, which leads to lots of heated comments (a.k.a. "badgering") in the oppose section as supporters try to win editors over. If we got rid of the support and oppose sections entirely, editors would no longer have a reason to try and argue with opposers who have already made up their minds. Editors would try and win over ASC members, of course, but assuming that members of the committee were rational people willing to look with an open mind at evidence both for and against a candidate, I would say that there would be a lot less potential for drama there. This format would have the added bonus of making it obvious that frivolous opposes (or supports) would be ignored by committee members. — Mr. Stradivarius ♪ talk ♪ 16:07, 27 November 2014 (UTC)
    It would put the focus on facts, rather than on percentages.
    The current system relies on a determination of community consensus. Under the proposed system, any request resulting in the support of seven commissioners (~54%) would pass automatically, regardless of the other six commissioners' concerns and those of the community. (Lest someone respond by pointing out that the number of commissioners is subject to change, I'm aware. This has no bearing on my point.)
    The current RfA discussion structure has a tendency to make editors worried about the number of opposes, which leads to lots of heated comments (a.k.a. "badgering") in the oppose section as supporters try to win editors over. If we got rid of the support and oppose sections entirely, editors would no longer have a reason to try and argue with opposers who have already made up their minds.
    Why not simply make such a change at RfA? (I've never cared for the separate "support" and "oppose" sections, even back when RfA functioned well.) I don't see why this requires throwing out the entire consensus-based approach and electing a new "commission" to make important decisions on the community's behalf via simple majority votes.
    Editors would try and win over ASC members, of course, but assuming that members of the committee were rational people willing to look with an open mind at evidence both for and against a candidate, I would say that there would be a lot less potential for drama there.
    Is there any reason to believe that the bureaucrats aren't "rational people willing to look with an open mind at evidence both for and against a candidate"?
    This format would have the added bonus of making it obvious that frivolous opposes (or supports) would be ignored by committee members.
    It's already obvious – from the plain wording of Wikipedia:Consensus – that the bureaucrats are to discount/disregard weak/invalid arguments made at RfA. The problem, as I noted previously, is that we lack a clear set of criteria regarding which rationales this describes. Instead of addressing said problem, this proposal calls for the election of a body whose members would be free to ignore any and all outside input and substitute their own judgement for that of the community at large. —David Levy 21:35, 27 November 2014 (UTC)
  16. Oppose per all above. --Fauzan✆ talk✉ mail 13:09, 27 November 2014 (UTC)
  17. Oppose Back during RFA2011 I thought the problems with RfA had been blown way out of proportion, nowadays when even Kudpung will say things aren't so bad it's strange to see the same vague rhetoric about "broken"-ness. On those grounds I see this as a solution in need of a problem and cannot spport. benmoore 16:13, 27 November 2014 (UTC)
  18. Oppose. What we don't need is people electing elected officials who elect other elected officials. We don't need a group of Soviet Commissars for Administrative Affairs! My name isnotdave (talk/contribs) 16:33, 27 November 2014 (UTC)
    This is where you get it wrong. The commissioners would be elected, but administrators would be appointed. We need to separate the politicians from the civil servants, as I've said from the start. Politicians have never made good civil servants, and they never will do. Rubbish about "commissars" strikes me as quite mid-century American, and quite uncouth. RGloucester — ☎
    Well I apologise for my bad wording -- even if it does mock the proposed process. I also apologise for the other remark, but considering the strong political viewpoints that you have espoused on this page, I thought it might be good to put it in some form of half-ironic context. I'm not a McCarthyist by any stretch of the mile.
    Nevertheless, if we can't trust the community on this issue, then we can't trust nobody. We have to take the risk of appointing someone with little competence -- after all, we do have a revoke button if things go wrong. My name isnotdave (talk/contribs) 18:17, 27 November 2014 (UTC)
  19. Oppose More committees ... more elections ... more titles .... more bureaucracy. RfA may have its problems, but this is not a good solution. Gandalf61 (talk) 17:10, 27 November 2014 (UTC)
  20. No. "There must be no cabal, there must be no elites..." User:Jimbo Wales/Statement of principles. This is a slippery slope. And I'm unsure of the rationale behind having six non-admins in the committee. If someone is experienced and trusted enough to elect a user to be an admin, they should be an admin themselves, and if they are not interested in being an admin, why are they getting involved in admin work? Being an admin doesn't mean you acquire any responsibility to do anything at any time - you simply have access to some extra tools. Being on this committee puts you under responsibility and pressure greater than that of being an admin. If you don't want to be an admin, why would you want to be on this committee? Motives and/or judgement must be looked into. And the election process for getting into the committee for non-admins would surely be worse than that for becoming an admin. I understand that people are concerned about admin recruitment and the painful crucible of RfA, but this is not a solution. This is the creation of a new problem. SilkTork ✔Tea time 17:43, 27 November 2014 (UTC)
    As I believe Jimbo established the Arbitration Committee, I'm fairly certain that he understood that certain matters are best dealt with in such a manner. You've got it all wrong. Some people don't want to be administrators because they don't want to play that role. These people, often vigorous content creators, are just as valuable to the project as administrators. All editors are equal on Wikipedia, and administrators need to understand that their tools are nothing more than tools. If only administrators are in charge of appointing new administrators, the result would be "old boys club" style nonsense. It would result in the creation of a cabal, exactly what you seem to rail against. A commission made up solely of administrators would be reluctant to review administrative actions, and would not be representative of a large part of the Wikipedia community. Non-administrators and administrators alike have an equal say in governance of the encyclopaedia, and, as such, they should have both have representation on the commission. RGloucester — ☎ 18:16, 27 November 2014 (UTC)
    I agree with the principle that "all editors are equal on Wikipedia" (in this context), but I regard your approach as antithetical to it. The creation of separate seats for administrators and non-administrators constitutes a formal declaration that they aren't the same (as does your statement that a group of administrators "would not be representative of a large part of the Wikipedia community").
    In response to your concern that "administrators would be reluctant to review administrative actions", I would expect non-administrators to be more reluctant, given that any aspirations of attaining adminship in the future would depend on support from a majority of a body comprising wither ~46% or ~54% administrators. (Conversely, admins might be reluctant to step on each other's toes, but they have less to lose in such a scenario.)
    However, I don't see why any of this is even relevant, unless you're concerned that the community might not be capable of electing thirteen editors who can be trusted to set aside their personal predilections and engage in an objective evaluation.
    Of course, neither of us advocates that the hypothetical commission consist solely of admins or solely of non-admins. I don't support the proposal, but were it to succeed, I would prefer that every seat be open to any editor (irrespective of whether he/she is an administrator). —David Levy 21:35, 27 November 2014 (UTC)
    No, my approach enshrines it. The cultural norms on Wikipedia, at present, give administrators a certain rank above everyday editors. That's a fact, whether we like it or not. As we've seen above, in SilkTork's comment, many people think that the only people who have an interest in governing Wikipedia either are administrators or should be administrators. This is a wrong-headed approach. We need to check these cultural norms, which are antithetical to the original conception of adminship. To do this, we must provide for non-administrator representation on this commission. I think that the community would struggle to elect non-administrators to this body if they were not reserved seats, and I think that that would be detrimental to both the encyclopaedia and the commission. This is seen in ArbCom now, where non-administrators are allowed to run for the position of arbitrator, but almost never attain it. The vast majority of editors have no desire to be an administrator. That doesn't mean that they should be excluded from the governance of the encyclopaedia. RGloucester — ☎ 01:08, 28 November 2014 (UTC)
    No, my approach enshrines it.
    It enshrines the concept that being an admin is a "big deal".
    The cultural norms on Wikipedia, at present, give administrators a certain rank above everyday editors.
    To the extent that such an attitude exists, it's a problem in need of fixing, not a principle around which to structure policies and procedures. The former might not be easy, and it certainly won't happen overnight, but it's our only hope of setting things right.
    As we've seen above, in SilkTork's comment, many people think that the only people who have an interest in governing Wikipedia either are administrators or should be administrators.
    I think that you might have taken those comments the wrong way. Adminship is supposed to be "no big deal". Trustworthy editors who wish to participate in the sort of process proposed (not that I endorse its creation) should be administrators – not because only administrators should be eligible, but because we should have no qualms about granting eligible editors adminship (thereby enabling them to view deleted edits, which can be highly useful when evaluating an editor's behavior).
    Of course, I'm well aware that such a climate no longer exists. And that's exactly why we're having this discussion. You've structured your proposal in a manner that formalizes symptoms of the problem it's intended to solve.
    We need to check these cultural norms, which are antithetical to the original conception of adminship.
    We need to eliminate them, not accept them as the new normal and attempt to counterbalance them through bureaucratic measures.
    I think that the community would struggle to elect non-administrators to this body if they were not reserved seats, and I think that that would be detrimental to both the encyclopaedia and the commission.
    Think about what you're saying. You want to create a rule explicitly intended to mandate an outcome that you believe is likely to lack consensus. Worse still, it would "enshrine" in policy the concept that we must maintain a pool of trustworthy editors without adminship. If seven of the commissioners were administrators, we would be unable to grant adminship to an eighth without booting one of them from his/her seat – no matter how trustworthy and reliable they are. You want to establish a rule that requires us to consider rank (a concept that shouldn't even exist in this context) before merit. And with what goal in mind? To counter discrimination on the basis of the aforementioned "rank".
    This is seen in ArbCom now, where non-administrators are allowed to run for the position of arbitrator, but almost never attain it.
    Correlation does not imply causation. The roles of administrator and arbitrator both require the community's trust, so significant overlap is neither unexpected nor undesirable. (And as noted above, the ability to view deleted edits can be highly useful when evaluating an editor's conduct.)
    The vast majority of editors have no desire to be an administrator.
    ...or a "commissioner".
    That doesn't mean that they should be excluded from the governance of the encyclopaedia.
    Nor does it mean that we should ensure their inclusion through affirmative action instead of getting to the root of the original discrimination. —David Levy 02:21, 28 November 2014 (UTC)
    No, you're wrong. My proposal makes it clear that administrators are dustmen with mops, and nothing more. Your insistence to the contrary is simply false. Technical workers, mechanics. RfA makes adminship a big deal because it requires users become political, as if they were vying for a position of leadership. This is antithetical to the role of dustman. One does not require that one run for election to be a dustman. A dustman does not need to run for election. He merely needs to do his job properly, in line with the policies and guidelines that the community relies on. I think that what is good for the encyclopaedia is "consensus", whether everyone agrees or not. That's how our policies work, and that's how this ought work too. The problem is not whether we should have any qualms about giving people adminship, but about whether they want it at all. Those that do not want it, the vast majority of editors, should have representation in the governance of this encyclopaedia. RGloucester — ☎ 05:54, 28 November 2014 (UTC)
    My proposal makes it clear that administrators are dustmen with mops, and nothing more.
    You just stated that "the cultural norms on Wikipedia, at present, give administrators a certain rank above everyday editors", and while you clearly don't approve of this, you've based your proposed system on the assumption that such a structure exists.
    I don't doubt that you want administrators to be thought of as "dustmen with mops" (and so do I). But your proposal doesn't reflect this.
    I think that what is good for the encyclopaedia is "consensus", whether everyone agrees or not. That's how our policies work, and that's how this ought work too.
    Under the proposed system, an adminship request would succeed or fail not on the basis of consensus, but through a simple majority vote.
    The problem is not whether we should have any qualms about giving people adminship, but about whether they want it at all.
    If someone doesn't want to be an admin, that's fine. Since first editing Wikipedia (initially without an account) almost ten years ago, I've been steadfast in my opposition to the treatment of administrators as members of a higher class. (This includes instances in which editors mistakenly believed that I was owed special deference, wherein I went out of my way to explain that I wasn't.)
    While I admire your intent, I strongly disagree with your approach (in which you seek to counter the practice of treating admins and non-admins differently by treating admins and non-admins differently – thereby reinforcing the concept and formally sanctioning it as a matter of policy).
    Those that do not want it, the vast majority of editors, should have representation in the governance of this encyclopaedia.
    Such statements imply that administrators are a separate group whose participation is disconnected from non-administrators' interests – that somehow, being given the sysop bit materially alters who they are and what they bring to the table (to the extent that they no longer "represent" the rest of the community). How is this consistent with the beliefs espoused above? Have you stopped to think this through?
    My position is that we're all Wikipedians. If a proposal such as yours were to succeed, I believe that Wikipedians should fill the seats. —David Levy 08:07, 28 November 2014 (UTC)
    I'm British, and in the House of Commons, everything is decided by a simple majority vote. That's consensus. Do note that the commissioners would not just be "voting", they'd be doing extensive research into the candidate. They would have to provide a detailed rationale to community. Regardless, we must counteract the dangerous cultural norms with proactive policy. If we do not, we will continue in this downward spiral. RGloucester — ☎ 15:59, 28 November 2014 (UTC)
    I'm British, and in the House of Commons, everything is decided by a simple majority vote. That's consensus.
    This isn't the House of Commons. At Wikipedia, consensus explicitly is not determined via a simple majority vote. I find it more than a little troubling that you either lack familiarity with the relevant policy or seek to override it with your definition of "consensus".
    Do note that the commissioners would not just be "voting", they'd be doing extensive research into the candidate.
    ...and then voting. As noted above, any request resulting in the support of seven commissioners (~54%) would pass automatically, regardless of the other six commissioners' concerns and those of the community. However sensible you believe such a process to be, it certainly isn't consensus-based.
    They would have to provide a detailed rationale to community.
    And no matter what that rationale is, as long as six additional commissioners cast the same vote, their position prevails. No matter what rationales the commissioners in the minority provide, their position is overruled. Only the vote count matters.
    Regardless, we must counteract the dangerous cultural norms with proactive policy.
    I regard the aforementioned system as far more dangerous than any problem it purports to solve. —David Levy 18:02, 28 November 2014 (UTC)
    It would be "consensus", because the consensus of the community would have implemented the commission. It would have granted them the power to make these decisions, much in the same it way ArbCom does. That represents the "consensus" of the community, because the community granted the power to the commission. Given that we have entrusted the commissioners to make these decisions, if we decide to implement the proposal, their vote represents our consensus. Adminship is no big deal, and shouldn't require a unanimous or two-thirds vote of commissioners. If there is a serious objection raised, I'm sure the other commissioners will take that into account, in line with common sense. RGloucester — ☎ 18:12, 28 November 2014 (UTC)
    It would be "consensus", because the consensus of the community would have implemented the commission.
    By that logic, one could define any hypothetical decision-making process as "consensus". I'm attempting to discuss the nature of the specific one proposed. Whether consensus for its implementation is established has absolutely no bearing on this. Consensus to replace RfA with a coin toss-based system wouldn't make coin tossing a consensus-based method.
    Of course, none of this relates to your previous statement, in which you referred to "a simple majority vote" as "consensus".
    It would have granted them the power to make these decisions, much in the same it way ArbCom does.
    Again, the ArbCom exists "primarily for serious conduct disputes the community has been unable to resolve" (or, as Philippe Beaudette wrote, to act "as a matter of last resort"). Conversely, you've proposed that the community cede a decision of the utmost importance – as a matter of course – to a 13-member commission, wherein a 7–6 majority would constitute "consensus" to elevate users to a "rank above everyday editors" (your words).
    The proposed Administrative Standards Commission would be an elected body tasked with making decisions, but its similarity to the Arbitration Committee begins and ends there. —David Levy 20:29, 28 November 2014 (UTC)
  21. No. The problem of needing more admins is not so apparent to me as to justify establishing a power center which by its nature would have influence outside its remit. The community judgment is that the pace of admin-making should be slowed, and it's rendered a verdict, unfortunate in my view in some cases, on some people. That's the community's answer. That's to be respected, not evaded.--Wehwalt (talk) 18:25, 27 November 2014 (UTC)
  22. Oppose - Nobody can be forced to be an admin. This proposals essentially would create a way how to promote some users to admins without the trust of the commmunity, and others who are inept, as long as they are friends with the appointing board. That is contrary to all basic principles of Wikipedia ("Community rules" and "Clue is required", especially). It would also increase the drama rate exponentially, for two reasons: Inept admins would make many wrong decisions which then have to be fixed, and then many of those admins would be subjected to recall, more drama. I think we can do without all that. Kraxler (talk) 20:16, 27 November 2014 (UTC)
  23. Oppose I would support such a board if it existed solely for dealing with the removal of admins. However, I cannot support disenfranchising the community in the promotion of admins. Mellowed Fillmore (talk) 20:19, 27 November 2014 (UTC)
  24. Oppose. I like the idea in principle. RFA is the most horrible job interview you will go through in your life. It goes on forever and questions come in from a multitude of random people, often with an axe to grind irrelevant to the candidate. We need a less stressful way of promoting suitable candidates to adminship. However, I cannot support any proposal that has quotas for admins and non-admins. The community should be free to appoint who they like to the Commission. I also do not agree with the simple majority principle. An RFA that was opposed by 49% of participants would be a clear fail. If 49% of the Commission oppose someone (people who are supposedly picked for their ability to choose good admins) that should carry even more weight. SpinningSpark 20:45, 27 November 2014 (UTC)
  25. Strong Oppose This proposal attempts to solve the problems of RFA by taking the power to promote admins away from the community and giving it to a small clique of elites. The proposal attempts to make this more palatable by requiring that the elite clique be elected, but this does not change the fact that users will be getting the mop without community approval. There’s also a risk that admins promoted without community consensus will be delegitimized, and any controversial decisions they make will be more subject to attack than if it was made by an RFA admin. At the end of the day admins should have the support and trust of the Wikipedia community, and attempts at RFA reform should not remove community consensus. Spirit of Eagle (talk) 02:22, 28 November 2014 (UTC)
    Never heard of the social contract, eh? They would have community approval, as the commission would be elected. These would not be "elites", but representatives of the community. This fear of "elites" is juvenile. We already have a large clique of "elites" on Wikipedia, and they are not even subject to elections. These fellows would be elected by the community at large to carry out an important function. They'd be representatives of the community, checked through elections. "Community consensus" is not a liberal ideal whereby everyone must voice an opinion. That doesn't happen now, and even if it did, it would be a rubbish way to appoint dustmen. RGloucester — ☎ 06:03, 28 November 2014 (UTC)
    To quote consensus policy: "Decision-making involves an effort to incorporate all editors' legitimate concerns". The proposal would only allow about a dozen editors to air their concerns while shutting out the general user base. While this group will be elected, it will serve to separate the admins from the userbase and prevent community consensus from occurring. You referenced the WMF to create precedence for the proposal, but that's not really a valid comparison. The WMF rarely gets involved in day to day editing unless there are legal issues or threats of lawsuits. Admins, on the other hand, have a massive impact on day to day editing. In light of this, I believe that admins should have the support of the general community. (Also, I get that most editors do not actually engage in RFAs in the present, but what matters is that they can if they have a strong opinion. Eliminating user participation in RFAs because many people do not participate would make about as much sense as canceling elections because many people do not vote). Spirit of Eagle (talk) 05:03, 29 November 2014 (UTC)
    Besides, any argument beginning with 'We already have a large clique of "elites" ...' is WP:OTHERSTUFFEXISTS. ekips39 06:04, 29 November 2014 (UTC)
  26. Strong Oppose. Creating an official cabal of elders to make the decisions on who gets to be an admin is probably the worst RfA reform idea that I have seen in ages. It will decrease transparency and credibility of adminship, and instead of decreasing the amount of drama will greatly increase it. Most problems with adminship have little to do with the RfA process itself but rather are caused by the continuing decline in the ability of WP to attract new regular editors and to retain existing ones. To the extent that the RfA process can affect the situation, what would be useful is a greater degree of unbundling of admin functions. The current system is based on the "all or nothing" approach: a user either has no admin rights at all (rollback really does not count) or gets all of them at once. Given that WP has grown rather big and complicated, such a system is no longer reasonable. For example, one can't really expect any user to have equally solid understanding of all the different aspects of the deletion policies, from CSD to images to user pages to DRV etc. Given the extremely wide array of tools that an admin gets access to and the vast amount of knowledge required to use these tools properly, it is actually pretty easy to trip any admin candidate by a few deftly chosen questions or to point out significant weaknesses that any candidate will necessarily have in some areas of admin responsibility. If the admin tools were unbundled and the stakes were not so high, it would be much easier to promote specific users to greater user rights in this or that narrow area, and their deficiencies in other areas would not matter as much. Farming out relatively low level admin tasks (e.g. blocking vandals and some forms of page protection) to a much wider group of users would allow "full admins" concentrate on more difficult tasks, such as deletion, dealing with ANI issues, etc. But the council of elders proposal is not the way to go. Nsk92 (talk) 02:52, 28 November 2014 (UTC)
  27. Oppose – On principle. We've debated for years what to fix RFA since the Kurt Weber, ageism, etc debates of 2007–2009, and clearly the consensus has not changed since then either that we cannot find a solution and that the system works as is, as broken as it may appear. More bureaucracy does not create a solution, but adds fuel to the fire, something I've argued for years. Mitch32(The imitator dooms himself to hopeless mediocrity.) 02:53, 28 November 2014 (UTC)
  28. Oppose creating more bureaucracy, more special positions. The proposal will reduce transparency and increase favoritism. The only solution, a hard one I admit, is to encourage more editors to stand for RfA, and to encourage better civility and respect at RfA. The RfA system is a good one if people apply more good faith. Jehochman Talk 04:27, 28 November 2014 (UTC)
  29. Strong oppose - Granted that Wikipedia is not a democracy, per se, it's a fatal defect that this proposal fails to satisfy the concept that the problems of democracy can only be solved by more democracy. Frankly, I think it's an appalling idea, easily subject to co-option, and more likely to produce more "dramah" rather then less, as every admin created under this proposed system would be suspect. I will grant that there are problems with RfA, and I do believe that those problems do actual inhibit some potentially useful editors from seeking adminship, but putting that kind of power into the hands of a small number of people is, it seems to me, a very bad idea. BMK (talk) 05:38, 28 November 2014 (UTC)
    I think that forcing dustmen to run for election is appalling. RGloucester — ☎ 05:59, 28 November 2014 (UTC)
    I think you don't have a clear idea of what "apalling" means. I also think that your propensity for responding to "oppose" comments is counterproductive, and an indication that you're being far too personal about this. Let it go. BMK (talk) 18:30, 28 November 2014 (UTC)
    I beg your pardon, sir. I didn't even want to put this proposal to an RfC. I only did so because there was an appetite for it, not because I have an interest in doing so. Given this, it is important that I put my energy into it, otherwise it would be a waste of time. I do have an idea of what "appalling" means. If you made everyone that wanted to become a dustman run for election, there would be very few dustmen. That'd be appalling. How would the everyday fellow manage all the rubbish building up outside his door? RGloucester — ☎ 20:43, 28 November 2014 (UTC)
    Your continuing actions and personalization of the issue speak volumes, and contradict your claim to be simply a neutral party. I suggest if that is indeed the case that you stop responding to comments and allow the community the freedom to decide without your further contribution to the debate.

    As for "appalling", no, you clearly do not know what it means. Having a "dustman" be elected might be silly, it might be stupid, it might be inappropriate, it might be a waste of energy, it might be "bureacracy run wild", it might be a lot of things, but it most assuredly is not "appalling". BMK (talk) 23:08, 28 November 2014 (UTC)

    I don't know what "personalisation" means. I have a self-declared density, in that way. I don't believe I claimed to be a "neutral party". I said I don't care what the outcome is. The world goes as it does, and if God wills it, something will happen. I believe that living in a house surrounded by accumulated rubbish is appalling. I'm sorry if you don't agree. I fear I wouldn't want to call on you, then. RGloucester — ☎ 02:47, 29 November 2014 (UTC)
    Well, what one person finds appalling doesn't necessarily hold true for everyone else, I suppose. I wouldn't say that's a misuse of the word. About dustmen, I'm not convinced it's an appropriate analogy to begin with. Dustmen collect rubbish, which by definition no one wants to keep around. Administrators, on the other hand, don't strictly collect rubbish. Some of the 'rubbish' they collect is valued by its creators, but no one else; some of it has been vigorously debated by a variety of editors, many of whom probably disagree with each other; and some of it is other editors themselves, whom it is offensive and dehumanising to liken to rubbish: while some 'editors' are not here to build an encyclopedia, often being here just to mess it up, others are genuinely trying to help, and many of these have been around for years and had a reasonable, even excellent track record before the time came for them to be dumped in the rubbish bin. Admittedly, different admins work in different areas, but 'rubbish' in the usual sense still isn't their sole focus by any stretch of the imagination. A better analogy would be policemen (though they are not elected either, so we are mostly back to square one). ekips39 04:46, 29 November 2014 (UTC)
    There is a reason why the symbol of the administrator is the mop. Their job is to clean up rubbish, and get rid of it. They remove vandals and vandalism, they delete rubbish pages, and they do what they can to keep rubbish out of articles. They are exactly dustmen, and I believe that we've got a lot of dust that's not being cleaned up. I know plenty of good and hardworking administrators. At the same time, I see intransigence across the administrator class. Many are reluctant to get involved in messes that are clearly detrimental to the encyclopaedia, even when they have tools like discretionary sanctions available to them. We must get past this intransigence. We must have dustmen that can remove rubbish, not dustmen that are afraid to do so. It is that simple. The first way to ensure that dustmen are capable of doing their job is by treating them like dustmen. Politics must be removed form the equation. RGloucester — ☎ 06:22, 29 November 2014 (UTC)
    That would be great. Unfortunately, the proposed system would introduce an additional layer of politics (campaigning for a seat on the Administrative Standards Commission) and simultaneously shift the existing politics to a less open, less transparent, more manipulable context. —David Levy 07:30, 29 November 2014 (UTC)
    No, it would allow dustmen to be dustmen, and allow politicians to politicians. Commissioners would be politicians, but administrators would be dustmen. This allows administrators to return to their original function, and removes their political role. This is similar to how Jimbo originally appointed administrators himself. That was a much better system, and if anyone cares to propose it, I'd support removing RfA and only allowing Jimbo to appoint administrators. RGloucester — ☎ 15:59, 29 November 2014 (UTC)
    No, it would allow dustmen to be dustmen, and allow politicians to politicians. Commissioners would be politicians, but administrators would be dustmen.
    Firstly, as I noted in my initial response to this proposal, we need less bureaucracy, not more. The way forward is to address the problem that's developed at RfA, not to "move the mess" (as Reticulated Spline described it) by making "elections" an official part of the adminship process. Secondly...
    This allows administrators to return to their original function, and removes their political role.
    If anything, it would have the opposite effect. Suddenly, the path to adminship would run through thirteen specific editors and their friends. Simply impress at least seven commissioners, and you're in.
    To be clear, I'm not referring to any sort of misconduct. I mean that the new form of "politicking" would be to behave in a manner most likely to be viewed in a favorable light by members of the commission (by participating in similar activities, expressing similar views, avoiding contentious areas, etc.). No longer would prospective administrators face torch- and pitchfork-wielding mobs, but we'd simply be trading that problem for a worse one.
    This is similar to how Jimbo originally appointed administrators himself. That was a much better system, and if anyone cares to propose it, I'd support removing RfA and only allowing Jimbo to appoint administrators.
    Wow. In an earlier reply, I nearly mentioned that option in jest (but decided that this was excessively hyperbolic). Your serious support is rather disconcerting. —David Levy 19:45, 29 November 2014 (UTC)
    And the other symbol of administrators is the banhammer. It's not often mentioned on Wikipedia, but one can think of the mop handle as serving that function, and in any case there is no denying its validity as a symbol. Reasoning of the form 'X is symbolised by Y, therefore Y is an accurate and full description of X' is fallacious because it confuses cause and effect. Finally, I'll reiterate that not all blocked editors are vandals, since apparently I was too long-winded the first time around and failed to make my point. How is any of this relevant? Because administrative tasks are not nearly so uncontroversial as to be merely collecting rubbish, and therefore we ought to take a good deal more care with administrators than with dustmen. The absurdity of electing dustmen has no bearing on whether to elect or appoint administrators. ekips39 20:58, 29 November 2014 (UTC)
    RGloucester's basic problem is that he has taken the symbols and analogies we use to help make clear what the role of a Wikipedia admin is and reified them into a hard-and-fast concrete concept which he takes to be the actual reality of that role. Thus, a "dustman" or a "janitor" can be helpful in understanding one aspect of an admin's job, and the mop can be emblematic of that role, but that doesn't mean that an admin is a dustman or that the janitorial role they perform is the only aspect of what they do. To RGloucester, however, an admin is a dustman, period, full stop, and therefore anything which applies to a dustman must apply to an admin. There's little need to point out the scope of this conceptual error, and the part it plays in his (clear and evident) advocacy of this terrible proposal. BMK (talk) 22:08, 29 November 2014 (UTC)
  30. Oppose RfA is the best transparent way and I have no problems with the process. Those who think the process deters editors, need to understand that editors must have confidence in themselves before running for RfA. This alternative is doesn't feel good. Harsh (talk) 07:48, 28 November 2014 (UTC)
  31. Very strong oppose There is nothing wrong with the RfA process. The perceived trouble is just a natural and unavoidable consequence of its open nature. The alternative, however, is to make the process less open and less democratic, for instance by having some commission in charge as proposed here. But this severely flawed. First, this proposal is far too underdeveloped to be taken seriously and should have been discussed in the Idea Lab first. Any serious replacement for RfA must be precise, e.g., how many commissioners, how are they elected, and so on. In fact, how would the election or appointment of commissioners be any less controversial than RfA itself? Plus, if there's a commission, it means fewer eyeballs scrutinizing candidates and that means a less thorough vetting process too. But the worst part of the idea is the extra layer of bureaucracy. This proposal would further erode the open nature of Wikipedia and it would probably cause more trouble than currently exists with RfA. Jason Quinn (talk) 14:18, 28 November 2014 (UTC)
    The point is to make it less open and democratic. Democracy is the problem, and appointment is the solution. Being "open" and "democratic" is not always a good thing. Perhaps you didn't read the proposal page at WP:ASC, but all of that stuff is already written. RGloucester — ☎ 16:04, 28 November 2014 (UTC)
    I did miss that link so until I get to read it I'm striking my one concern above but changing the RfA process to be less open and less democratic is why I'm saying this proposal must fail. This comes bundled with a whole new set of troubles that I don't think are worth the effort, not the least of which is taking Wikipedia one bit further away from being the "encyclopedia any one can edit" by centralizing power. Otherwise your comment seems consistent with what I wrote. Jason Quinn (talk) 07:46, 29 November 2014 (UTC)
  32. Oppose Half-baked with insufficient ground work done before the proposal ever saw the light of day. Proposal after proposal has died because people refuse to do any sort of problem identification and problem solving, and instead come up with a solution that will fix everything (though they don't know what the 'everything' is). I will not support this nor any other proposal that refuses to proceed in a horse before the cart fashion. Just because someone can come up with a solution doesn't mean it addresses any problems that truly exist. --Hammersoft (talk) 15:38, 28 November 2014 (UTC)
    The problem is mob democracy, and the way RfA makes editors become politicians in order to become an administrator. They should be civil servants, and civil servants are not elected. My proposal renders them into their proper role. RGloucester — ☎ 16:04, 28 November 2014 (UTC)
    With respect, you don't really know. Lots of people have ideas about the problems of RFA but nobody has done a true analysis. --Hammersoft (talk) 17:23, 28 November 2014 (UTC)
    #Strong Oppose - I might support this as supplementary to RfA, but I doubt it. This essentially removes the ability of the community to decide who is or isn't worthy of being an administrator, which I find is quite important. Further, it removes the ability of the applicant to discuss the reasons why people oppose them; this is something that, as an admin hopeful, I feel I need. When I apply for adminship, part of the point will be to get that feedback on my conduct whether or not my request is successful. RfA may need improvements, but a committee to appoint administrators is not the solution. demize (t · c) 16:47, 28 November 2014 (UTC) Moved to support demize (t · c) 00:59, 1 December 2014 (UTC)
  33. Oppose RFA needs a wide range of input across the community, people who have past knowledge of the candidate and those who can did into their past actions. I can't see how the ASC could get a broad enough range of views. What I would like to see is the bureaucrats playing a much more active part in moderating RfA to eliminate the nastier end of the comments.--Salix alba (talk): 19:17, 28 November 2014 (UTC)
  34. Oppose I understand the urge to replace or supplement a process that is deemed "broken" (although it managed to make a lot of good users admins) but this proposal doesn't seem to be a step in the right direction. Those who claim that this proposal will remove the "democracy"-problem with RfA fail to see that it just shifts it to another level. Not the admin candidates would have to be politicians then but those who want to serve in the ASC. Also, the proposal as it currently stands would allow seven editors working together to appoint a large number of bad admins or to block a large number of good editors from becoming admins. I'm not completely opposed to concentrating power when it serves a valid purpose (e.g. with ArbCom to have an efficient dispute resolution process) but any concentration of power in the hands of a few editors should neither be the first nor the only resort (which is why ArbCom is the final step in the dispute resolution process for example). Regards SoWhy 21:16, 28 November 2014 (UTC)
  35. Oppose - Wikipedia needs better, more neutral administrators, not more administrators. Guy1890 (talk) 21:21, 28 November 2014 (UTC)
  36. In this case, it is incredibly naive to believe that a less transparent process would lead to a more desirable outcome. There is no assurance that this process will address the existing problems in RfA regarding low amount of applicants - instead all it does is shift the power from the community towards select individuals. Instead of demonstrating competency towards the community, they will instead need to campaign towards those individuals. It is a dangerous assertion to make that these individuals are more capable of making this decision than the community. Is it more likely that more people will be promoted through this process? Probably. Will the candidates be similarly vetted and tested for competency? Probably not. —Dark 04:26, 29 November 2014 (UTC)
  37. Oppose I'm also concerned that the commission could easily tend towards cliquishness, that this proposal amounts to swapping democracy for oligarchy, and that it would be very difficult for a commission to really know all would-be administrators, especially without excessive politicking. --BDD (talk) 14:10, 29 November 2014 (UTC)
  38. Oppose I do not want a competing process to RfA. I am not convinced that the problems described are serious enough to merit this drastic and shocking change. I would support the creation of a board to support the community in other ways, but I am not convinced that granting more userright flags is going to improve community health. Blue Rasberry (talk) 23:59, 29 November 2014 (UTC)
  39. Oppose I feel that community support for sysops is an essential requirement. Further, adminship through ASC would make the position truly special, a status that is already contested as being a "big deal" when it shouldn't be. Mkdwtalk 00:09, 30 November 2014 (UTC)
  40. Thank you, RGloucester, for your willingness to think critically about RFA and your courage in bringing this proposal forward despite the contention you must have known you'd get. The proposal has its merits, but I must oppose it. Democracy guarantees very little, except that we deserve the leaders we get. Wikipedia must always deserve its admins. Lagrange613 02:59, 30 November 2014 (UTC)
  41. Oppose Not the right solution. wctaiwan (talk) 04:57, 30 November 2014 (UTC)
  42. Oppose Reforming the RfA is a good idea, but a new committee is (mostly) a step in the wrong direction. I would much rather support putting a term limit on adminship (repeat adminship possible), and incorporating a review of user's recent admin/admin-like actions as a more explicit factor in the RfA process. Having admins appoint other admins seems to counter the crowdsourcing spirit of Wikipedia.Forbes72 (talk) 06:06, 30 November 2014 (UTC)
  43. Oppose - RFA should be a community thing still - Yes we have far to many people and yes the RFA needs sorting but IMHO cutting all the community out isn't the answer, What happened if some admins thought "hmm yeah this persons perfect for the bit" when basically the entire community would've maybe thought otherwise ..... then all shit would hit the fan no doubt, It's a great idea but just don't think it'll work here for long sorry, –Davey2010 • (talk) 06:10, 30 November 2014 (UTC)
  44. Oppose I don't at all like the idea of a few people deciding who should be admins when the admins are supposed to have the support of the community to enforce its consensus. Also given that the WMF has sad numerous times that they require an editor to be selected by an RFA or RFA-like process before being granted access to deleted content I don't see how this could work. Callanecc (talk • contribs • logs) 12:28, 30 November 2014 (UTC)
  45. Oppose per the previous opposes. I think each person in the community needs to be able to have a voice in deciding who becomes an administrator. I don't agree with the rationale that democratically-electing admins is the problem with RFA, or that making the process into a bureaucratic one involving a cabal that appoints admins would be an improvement over the current process. The way I see it, the problem with RFA isn't the fact that the community elects administrators - it's that there's a lack of guidelines for voting and so people, being people, will use their own guidelines and will make the process difficult. Although the RFA process needs to be improved, I don't think this proposal will improve it. Ca2james (talk) 17:38, 30 November 2014 (UTC)
  46. Weak oppose: This idea might have potential—especially for desysopping—but its structure gives whoever's on the commission a great deal of power, and systems that concentrate power are generally not in Wikipedia's interest except as necessary evils (like ArbCom). RfA has its share of problems, but it at least reflects the idea of "community trust" as the baseline requirement of adminship. {{Nihiltres|talk|edits}} 19:57, 30 November 2014 (UTC)
  47. Oppose, reluctantly, since I think something on these lines would be useful; but the question asked is "Should we implement this proposal as specified," and I cannot support this as written. First, I disagree strongly with attempts to cast admins and non-admins as separate groups with conflicting aims who need constitutional protection from each other. Certainly, this body should not be admin-only, but I think it should be left to the electorate to choose the people best qualified for the work, and I hope the Commission would operate by discussion and generally by consensus, not dividing along party lines. People who believe that existing admins want to make appointing new ones difficult so as to cling onto their POWER (Mwahahaha!!) should consider that they are greatly outnumbered in the electorate, and so are unlikely to be able to dominate this Commission if they are generally distrusted. At most, reserve three seats each for admins and non-admins, to ensure they each have some representation. Even more, I disagree with appointment on a bare majority. We should not be aiming to lower the standard, just to make the selection process less stressful. The Commission should not appoint a candidate who six of them think unsuitable; I would want to see at least a 10 - 3 majority. Finally, I think the idea that this group should also be searching for candidates involves a degree of COI: they may be reluctant to criticise a candidate sponsored by one of their number. Searching and selection should be separated. JohnCD (talk) 21:26, 30 November 2014 (UTC)
  48. Oppose. Editors have been having endless disussions about what's wrong with the RfA. This proposal is one result of the dissatisfaction and impatience with the current process. I respect the creator of the proposal and many of the support voters as well, but I, like many others, don't think this is the answer. We don't need another bureaucracy that somehow interrelates with bureaucrats and the community and ArbCom and god knows what else. I also see people complaining about this process if it were implemented. Although I am not opposed to fixing what is "wrong" with the current process, I think we may have to accept that no process is without flaws. Perhaps then our expectations will be more reasonable as to what can be done.--Bbb23 (talk) 23:45, 30 November 2014 (UTC)
  49. Oppose TLDR: Adminship is not a big deal. Their selection process should reflect that.
    In reply to SilkTork (oppose #20), RGloucester said that "Some people don't want to be administrators because they don't want to play that role." Perhaps. But what role is that? Administrators are enabled to do a wide variety of things - and required to do none at all. There is no role for an admin. Being an admin just means that you are generally familiar with the encyclopedia and its policies, have shown that you can follow them, and have minimal good judgment.† And it means you get to help out occasionally when you see a problem. It is no big deal.
    Current admin selection tries to reflects that - it follows a procedure roughly comparable to that of deleting a page. There's a discussion, then a decision. And if not everyone quite agrees on what the guidelines for making that decision are, it's still done as a simple, routine process. Conversely, if this proposal is adopted - a special, globally elected commission dedicated to selecting admins - we will be saying that being an admin is not merely a big deal, but such a big deal that the community can't be trusted to make the selections on its own. That being an admin is such a huge deal that it takes a special commission on the level of ArbCom to select them. I shudder to think what that could do to the role of the admin. – Philosopher Let us reason together. 01:43, 1 December 2014 (UTC)
    † Yes, I said minimal - and that's all that's needed for most admin purposes. Most of the truly complicated cases or cases that require more-than-minimal judgment are discussed by the community, reducing the admin to mere button-pusher. Similarly, while there are a few areas that require some particular expertise, that same minimal judgment will tell the admin to stay away until they've acquired that expertise. Which is why we don't grill all candidates on all areas of becoming an admin in every RfA. – Philosopher Let us reason together. 01:43, 1 December 2014 (UTC)
  50. Oppose Per the above. There are bad apples in the community, but thats a problem for the community to fix, and a reason to shift away from democrtically elected administrators. Haymaker (talk) 03:00, 1 December 2014 (UTC)
  51. Oppose The system we have has worked for years now and per above. - Knowledgekid87 (talk) 03:52, 1 December 2014 (UTC)
  52. Oppose. The politicization of adminship — the afaik widely-acknowledged fact that those who want to help the project as admins can't edit controversial topics before seeking the vote, lest people oppose them for having the 'wrong' position on the topic — is a problem. But I don't think this proposal solves the problem: when US senators were elected by state legislators rather than directly by the people at large, they were not any less political / partisan. They were, however, less accountable / harder to hold to account. -sche (talk) 04:03, 1 December 2014 (UTC)
  53. Oppose – Nothing wrong with the current system. – Smyth\talk 11:22, 1 December 2014 (UTC)
  54. Oppose. I don't like the way this moves adminship away from the community. Anyone should be free to present themselves as an admin candidate and find out what the community thinks about them. There have been people in the past who opposed all self-noms, or opposed candidates who hadn't worked on featured articles -- these shouldn't be the gatekeepers for whether an adminship request succeeds or not. --SarekOfVulcan (talk) 18:34, 1 December 2014 (UTC)
  55. Oppose - There is wrong with the RFA process. The problem is that there are many editors who are active, and in good standing, who really ought to be admins, but aren't. Having been an admin for a number of years, it really is "not a big deal". It is useful having the tools to be able to step in and deal with non-productive editors at the click of a mouse, rather than having to ask someone else to do so. It is also useful sometimes in being able to correct one's own errors! One fear I had when I decided to run for adminship was that it would cut down on my editing. This has generally not proved to be the case. As an admin, you don't have to get involved in any dispute or deal with any case should you chose not to. If you are eligible, please consider running, you never know, you might even succeed! Mjroots (talk) 21:03, 1 December 2014 (UTC)
    Or, if you don't succeed, you might become one of the people who are so disgusted by their colleagues that you quit editing (or cut back significantly). I don't honestly remember the last time I encouraged someone that I liked to undergo RFA; it's probably been several years. WhatamIdoing (talk) 19:56, 2 December 2014 (UTC)
  56. Oppose - This proposal to make a substantial additional bureaucracy to run parallel to the current system and disenfranchise much of the community is not the appropriate change to make at this time. I agree with Jehochman that we must "encourage more editors to stand for RfA, and to encourage better civility and respect at RfA." - tucoxn\talk 22:20, 1 December 2014 (UTC)
  57. Oppose the creation of additional bureaucracy which would only serve to remove the community from adminship decisions and put the power in the hands of a shadowy cabal. Mihaister (talk) 23:21, 1 December 2014 (UTC)
  58. Oppose Although I respectfully disagree with Chris troutman above, I think this would be a step in the wrong direction. Miniapolis 23:55, 1 December 2014 (UTC)
  59. Oppose --Surturz (talk) 03:15, 2 December 2014 (UTC)
  60. Oppose: To me, the most important thing to remember about being an admin is that IT'S NO BIG DEAL. AT ALL. With every step towards creating a more elite process, that fundamental truth gets lost. This process seems to not only "christen" certain chosen editors, but then add an ADDITIONAL level of even more prestige--the admin appointing oligarchs. Admins are just editors with extra tools, and the culture needs to swing towards reinforcing that notion and not creating a hierarchy. What makes Wikipedia one of the top 5 internet sites is not the police, but the law-abiding citizens, toiling away on making better content. And if the requirement to be able to add content is "Anyone can do it, unless you abuse the privilege," that should be the basic requirement for being an admin as well. Some bureaucracy is necessary, but it should be viewed as a necessary evil that we should be backing away from every chance we get—not expanding. Our energies need to be going almost 100% towards what will DISqualify you as an admin, not what will qualify you as one. I would just as soon give it to anyone who wants it, and only snatch it if and when they begin to abuse it. The fact that Wikipedia:Requests for de-adminship is underdeveloped is the core of the problem.--Esprit15d • talk • contribs 04:47, 2 December 2014 (UTC)
  61. Strong Oppose I didn't think it was even possible to create a more opaque bureaucratic system than the one WP already has, but I was clearly wrong. Word "Kafkaesque" readily comes to mind. Primaler (talk) 05:56, 2 December 2014 (UTC)
  62. Oppose - more bureaucracy, more clique-e-ness, less accountability for admins, less community control? That's 0/4. WilyD 14:54, 2 December 2014 (UTC)
  63. Oppose Especially the part giving the power to remove administrators--as I understand it, without the involvement of arb com or even an appeal to arb com. This would in effect create two arb coms, and we have trouble enough managing the associated bureaucracy of our single one. And if it does allow an appeal to arb com, essentially every removal will probably be appealed there, it's just adding an extra step and prolonging disputes. DGG ( talk ) 20:31, 2 December 2014 (UTC)
  64. Oppose I agree that RfA needs to be improved, but I'm not convinced this process would make it less of a hell week. My own RfA was fairly stressful (mostly because I gave a bad initial answer to one of the questions), but most of the people arguing over my answer were pretty established editors anyway (including a few arbitrators). When your answers and editing history are being relentlessly picked over for mistakes, it doesn't matter if thirteen or a hundred-odd editors are doing it - and if most of the committee hasn't interacted with the candidate, that part might even get worse. TheCatalyst31 Reaction•Creation 04:21, 3 December 2014 (UTC)
  65. Oppose Super bad idea. Feels like bureaucrats are gradually stealing WP away from the community. – nafSadh did say 04:54, 3 December 2014 (UTC)
  66. Oppose Too much process wonkery, potential for less oversight. SpencerT♦C 05:08, 3 December 2014 (UTC)
  67. Oppose: After thinking on this for a long time, I'm coming down here. I think that having an appointments board would create a de facto two-tier ranking of admins – elected and appointed – which would be toxic and cause conflict, giving those who dislike an appointed admin a stick to beat them with. On desysoppings, we already have ArbCom and efforts should be on improving that system. Likewise, the recent run of successful RfAs shows it's not broken, we just need to encourage people who have been discouraged by the negative hype around it. BethNaught (talk) 17:27, 3 December 2014 (UTC)
  68. Oppose Don't really see the problem with the current system, and especially no need for the creation of a bunch more special positions. IMO, a system that works by appointment is a very bad idea – we only have to look at the House of Lords to see what inevitably happens... Even more concerning is the part of the proposal re revoking admin rights – it's quite easy to piss a small group of people off (particularly if they have the same mindset), and I'm concerned this could lead to a few ANI-type witchhunts where decisions are made on spurious evidence in a short time period. Number 57 19:51, 3 December 2014 (UTC)
  69. Oppose: I don't think this is a terrible suggestion, and do believe it's motivated by a sincere desire to improve the process of selecting admins. Nevertheless, I don't believe that adminship will be improved by electing commissioners who then nominate editors. While this proposed practice may increase the number of needed administrators, and obviate the requirement that editors be especially diplomatic, I believe that diplomacy and cool-headedness is one of the characteristics we rely most on in admins, even when many of their actions are simply bureaucratic. Furthermore, because of their substantial powers, I would rather that the entire wikipedia community participate in the selection process. As messy as this democratic process is, I believe it works far better than in most democratic examples to be found outside Wikipedia. -Darouet (talk) 21:33, 3 December 2014 (UTC)
  70. Oppose on principle of not disenfranchising the community in this process. Per Mellowed Fillmore and others. Michael Barera (talk) 23:22, 3 December 2014 (UTC)
  71. Oppose, while the current system has issues, the proposed system is not any better. Reading the opening line of the WP:ASC scream "Good old boy network. Jeepday (talk) 23:40, 3 December 2014 (UTC)
  72. Oppose This will just bureaucratize the system. May be next time we need another committee to address the issues related to ASC and the procedure of committees being invented will continue! This is not what we should do. Admin is "One who administers, especially one who works as a manager in a business, government agency, or school 1" Mhhossein (talk) 03:45, 4 December 2014 (UTC)
  73. Oppose. The solution to bureaucracy is not more bureaucracy, nor more special hats, nor more processes. Stifle (talk) 09:32, 5 December 2014 (UTC)
  74. Oppose - Creating more (or different) forms of bureaucracy goes against what "the Community" needs - which is as simple and efficient a means as possible to enable more established and competent users to undertake administrative tasks, ultimately in support of core purpose of creating and curating encyclopaedic content (while encouraging a mindshift to recognize that adminship should not be viewed as such a "big deal" that otherwise trusted and capable editors are discouraged by a toxic process from even attempting to obtain access to the necesssary admin tools). Azx2 23:33, 6 December 2014 (UTC)
  75. Oppose reluctantly. It has always been my opinion that people should only be granted adminship if they have the confidence of the community and should only loose it if they don't, and creating a Commission is only going to move us further away from that principle. I'm open to some very serious reforms at RfA to streamline the process and encourage more candidates to step forward, but this is not the way to go. CT Cooper · talk 22:12, 8 December 2014 (UTC)
  76. Strong oppose: This wiki does not need more bureaucracy and more vested power in a very small clique of editors. Community approval is the purpose of RfA, it's worked well, and we simply do not need to shatter one of the foundations of this wiki. T3h 1337 b0y 19:38, 11 December 2014 (UTC)
  77. Oppose. While the idea behind this proposal is interesting, and presented with good faith, its basis is unproven (saying "RfA is broken" over and over doesn't actually prove that it is; currently it seems to be functioning fairly well), certain of its supporters appear to be overly invested in it and arguing too fervently (which leads me to suspect their emotional involvement is impairing their clear vision), and, like many above, i suspect that another layer of bureaucracy isn't what WP needs. In addition, though i am open to correction, i have not in all the words above seen anything legitimately indicating that the WMF will accept this proposal as a meaningful replacement for the kind of public vetting they have made clear they require; it has been asserted, and stated not to matter, but i believe that the WMF would surely have to sign off on it for this to go ahead, no? Cheers, LindsayHello 12:44, 12 December 2014 (UTC)
  78. Oppose. I think there is a problem that needs to be solved, RfA is broken, but there is currently no social construct on Wikipedia to support this proposal. Every administrator is his own god, making up his/her own rules and decisions as he/she wants. And while some of the gods are, or think they are, more powerful than other gods, and a few of the lesser gods might well be amiable and wise, none of then will ever do anything to risk the continued existence of gods as a concept. They will simply subsume this new Administrative Standards Commission to reinforce their own status, because only a god can create another god (and it is alarmingly easy to become a god if another god is your sponsor). Something more revolutionary is needed. Maybe an actual written social contract, one that no administrator can ever trample over. Then once that is established, things like the suggested can be tried. Tiptoethrutheminefield (talk) 04:04, 13 December 2014 (UTC)
  79. Oppose oppose firstly on the ground of not wanting more bureaucracy, and secondly have you thought of what elections to this bureaucracy will look like, all the negatives of the current RfA process being boiled down, concentrated, distilled, and intensified. You will retain all the negatives of the current system and introduce new ones. When power becomes the gift of a body to give, the dangers of cronyism and patronage rear their head, and for those who receive patronage, Tammany Hall politics, the repayment of favours with favours.--KTo288 (talk) 09:11, 14 December 2014 (UTC)

Neutral (alternative to RfA)

Tentatively neutral extended comment moved to support Ivanvector (talk) 18:34, 26 November 2014 (UTC)
  1. OpposeNeutral - I'm strongly in favor of a major reform to the process by which we appoint and remove users from the admin role. As I mentioned on the proposal talk page, I can not support this proposal as written. I agree with the idea of specifically allocating a minimum fixed number of seats to non-administrators. I disagree with specifically allocating a minimum fixed number of seats to administrators. Of course nothing would stop them from being elected to seats that are not allocated to non-administrators. I also have some concerns about transparency, but I'm open to persuasion on that issue.- MrX 17:14, 26 November 2014 (UTC)
    As said above, the particulars of the implementation are open discussion. If you'd like to propose a change, please do so in the discussion section above. If you at least support the principle, I would ask for your voice of support, or even a voice of what one might call "neutrality". We have a very narrow window, here, and I'm willing to do whatever work needs to be done to try and get real reform through. RGloucester — ☎ 17:27, 26 November 2014 (UTC)
    The RfC states "Should we implement this proposal as specified at the proposal page?" (emphasis added) That doesn't convince me that we're now voting on the idea and will vote on the specifics later. I am more or less neutral on the idea of an admin commission (if properly constituted). I support the idea of a major reform of some sort, mainly because I think we need a streamlined process for desysopping.- MrX 17:49, 26 November 2014 (UTC)
    Nothing in our policy or processes is ever set in stone. That's especially true of a newly formed process. If this passes I'd fully expect a couple follow-up RfCs to sort out details. Gigs (talk) 17:58, 26 November 2014 (UTC)
    That's true, but if this proposal passes, the commission would have seats specifically reserved for admins until such time that the community decides to change it, if it ever does. For that reason, I can't support this.- MrX 20:10, 26 November 2014 (UTC)
    Would you like to elaborate on your concerns? RGloucester — ☎ 04:55, 27 November 2014 (UTC)
  2. Tentatively neutral - we'd be treating a symptom while ignoring the cause of the disease. Poorly written articles (undue weight, NPOV, OR, BLP, N, V, RS, etc.) are, for the most part, the cause which creates the need for ANIs and admins. But what if articles were reviewed in a close or similar manner to the way FAs are reviewed? I think a big part of the problems would disappear. Instead we are dealing with open editing from a variety of persuasions and perspectives, much of which are based on POV, and we end up with articles that are not worthy of inclusion because they are plagued by multiple guideline issues and/or policy violations. RGloucester wisely mentioned above that it should be about quality, not quantity. I see many problem areas that if eliminated, would help eliminate many of the disputes and disruptions on Wikipedia, possibly even this issue. Example: I've seen templates that were created under the guise of being a navigational aid for readers but more often than not, they are nothing more than contentious labels based on POV. There is no evidence that such templates actually aid a reader in navigating the encyclopedia, so what real benefit do they serve when we know they give rise to ongoing disputes? If removal resolves the disputes and disruption, why are we perpetuating the fight? By eliminating the root cause of the controversy and disruption, we are resolving many other problems as well. Another example of a problem area that can be resolved includes articles about religion, politics and a percentage of BLPs, all of which are known to be controversial. They are definitely topics we tend to avoid on a first date. Perhaps they could be reviewed like an FA using a qualified editorial committee (with teeth) comprised of neutral reviewers whose decision is final. We already have a Peer Review process, Wikipedia:WikiProject_Guild_of_Copy_Editors, and Wikipedia:Cleanup that, if properly combined or united would eliminate a lot of the problems plaguing controversial articles. Attack the problem before it spreads rather than the reverse as we've been doing. Early detection is key to the cure. Atsme☯Consult 17:54, 27 November 2014 (UTC)
    1. Your comment would make more sense if we could keep a handle on the AfC backlog. And that's just a basic filter for some sign of probable notability and suitability for the encyclopedia, it's not the kind of detailed review you are asking for. And it's only a fraction of the new article stream! We simply don't have the manpower at all to drink from the firehose the way you are proposing. Gigs (talk) 17:26, 15 December 2014 (UTC)
  3. Neutral I can't discount the significance of the issues with the RFA process anymore than I can discount the concerns raised regarding this particular proposal at this point in time. I will reconsider this again later. Ncmvocalist (talk) 17:09, 28 November 2014 (UTC)
  4. No opinion since I haven't read any of the text above and don't intend to. Proposals like this (whatever it is) have zero chance of ever going thru, so why waste time. I see that the vote currently is 27-34 against, but the exact numbers don't matter. To have a ghost of chance of going thru you would be wanting something along the lines of 40-20 in favor, at the very least -- and that, my friend, you are never going to get, and that applies to most any major proposal along these lines; the more people participate, the more the count tends to devolve to 50-50, which means no decision. The current RfA process is what we have and what we going to have going forward, for better or worse. It is what it is and I wouldn't waste too much time worrying about it. Herostratus (talk) 19:40, 28 November 2014 (UTC)
  5. Neutral I haven't read this entire section, but I kind of like the idea for such a commission. What I'm concerned about though is that it might create too much bureaucracy. The community at large should have a direct say as to who becomes an administrator. So, I'm going to stay neutral on this for the moment. Sam.gov (talk) 00:05, 3 December 2014 (UTC)
  6. Neutral. How about we give it a test run of a year as an advisory body? I.e. this body would issue recommendations on whether the community should support or reject a candidacy. It could become a helpful guide for some voters, and a test in how such a body would operate compared to the current system. --Piotr Konieczny aka Prokonsul Piotrus| reply here 02:30, 5 December 2014 (UTC)
  7. Neutral - I'm not against reform of the RfA process; it is a bear pit of disfunction, However, I'm not sold on this as the answer. I'm also afraid that it would lead us further away from where we started, as a volunteer-run charity, and not in a good way. Bearian (talk) 01:24, 9 December 2014 (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.

Something more helpful than [edit] near section headers on the Help Desk

Mandruss proposed on WT:HD that [edit] or [edit source] by section headings be replaced or supplemented by something more friendly (and sensible) like [Continue discussion] on WP:Help Desk. We may as well use the same kind of hovering text box as used in the Teahouse. This is considering the fact that many of the Help Desk visitors are newbies, and after posting a query, may not know how to continue the discussion. --Fauzan✆ talk✉ mail 16:25, 11 December 2014 (UTC)

I'm for that. ;) ‑‑Mandruss ☎ 01:12, 12 December 2014 (UTC)

Hear, hear! Tharthandorf Aquanashi (talk) 01:47, 12 December 2014 (UTC)

Since there is at least no consensus against doing so, WP:BOLD? --Fauzan✆ talk✉ mail 18:21, 17 December 2014 (UTC)

Copy and paste detection

We have had this bot running on articles associated with WP:MED and WP:PHARM for 6 months. When it flags a concern more than half the time it is correct. In the last few months we have had more than 200 true positive issues it has helped us fix. Wondering if other projects are interested in having this run on their articles? Does require human follow up. Doc James (talk · contribs · email) 06:17, 18 December 2014 (UTC)

Added as a suggestion for bot tagging of suspected copyvios. Cenarium (talk) 12:24, 19 December 2014 (UTC)

Proposal: enable "Syntax highlighter" gadget by default for all editors

Syntax highlighter in action

In my 10 years editing Wikipedia, no other tool has been as helpful in making editing more friendly than the Syntax highlighter gadget. I can think of no reason this shouldn't be enabled for everyone (with an option to turn it off for the few who will inevitably dislike it). I am also experienced in teaching newbies about Wikipedia - I have taught over a 100 student editors - and all them unanimously said they prefer editing with rather than without this gadget. Even if one dislikes it (and I can't really think why), I'd urge you to allow it to be the default add-on for the majority whose editing experience is going to be vastly improved as a result of turning this on. Ping creator, User:Remember the dot. --Piotr Konieczny aka Prokonsul Piotrus| reply here 02:39, 5 December 2014 (UTC)

The Known issues page for this tool says it does not work with Internet Explorer. I would oppose making it the default unless it some mechanism can detect the editor is using Internet Explorer and disable the Syntax highlighter for those editing sessions. Jc3s5h (talk) 02:49, 5 December 2014 (UTC)
While I see your point, the tool, as far as I can tell, causes no problems in IE - it just wouldn't change the default behavior of IE at all. I have tested IE a bit (a few student prefer it, and I observed them too) and nobody ever run into any issue. It would be great if the gadget could work with IE, but it not working with it doesn't affect anybody much. We should not deny this tool to Chrome/Firefox users because IE users would not benefit from it... --Piotr Konieczny aka Prokonsul Piotrus| reply here 02:59, 5 December 2014 (UTC)
I haven't tried it in IE; it would need to be tested before it becomes a default for IE users to determine that it at least does no harm. The developer(s) would have to commit to testing new releases in IE to insure they don't break anything. Jc3s5h (talk) 03:29, 5 December 2014 (UTC)
I've revised mw:User:Remember the dot/Syntax highlighter#Known issues to clarify that the highlighter will not even attempt to execute if Internet Explorer is detected. This was a condition of making it a gadget in the first place. —Remember the dot (talk) 06:08, 5 December 2014 (UTC)
  • Opposed for now as I'm more concerned with the technical implications and what conflicts it may have with other gadgets that are much more powerful and useful such as wikEd (even just wikEddiff). If we were going to make some tool a default, I would much prefer this much more powerful tool. I do have a couple minor concerns with that as well, I know it had issues coexisting with the code editor, but code editor seems to have disappeared. I'd like to see much more testing of either gadget before deciding it should be a default on gadget. This seems like a decent candidate for an Individual Engagement Grant to see what more new editors and readers who may edit anonymously on occasion might think. Please ping me with a link if a proposal is made there. — {{U|Technical 13}} (e • t • c) 04:35, 5 December 2014 (UTC)
    wikEd won't highlight syntax as you type it, and on Linux it disables the Ctrl+Shift+X shortcut for "Redo". The syntax highlighter also has the advantage of being much smaller and faster to download compared to wikEd. I'm ambivalent about turning the syntax highlighter on by default, but I definitely do not want wikEd on by default. Oh, and if you find a bug in the syntax highlighter, please report it to me. —Remember the dot (talk) 06:08, 5 December 2014 (UTC)
    • Rtd, I think you're missing my point, which may be my fault if I poorly worded it. Let me "try" to clarify. While I appreciate your tool, and am happy to hear that new users working on small pages seem to benefit from it, I think the proposal here was poorly thought out and poorly excuted in a way that I believe will doom It to failure. What I propose is for Piotrus to officialy withdraw this proposal and you and them (and I'm willing to help in any way I can) thoroughly test this script in all environments (OS/browser/skin) available and make sure it works. While working on that, I'd love to see some research done by the WMF per a grant like I suggested above to see how beneficial it is to "non-regular" editors. Based on that data, and having a fully functional script, then take some time putting together a well thought-out and worded proposal for this again. Does that sound fair and reasonable? — {{U|Technical 13}} (e • t • c) 21:01, 5 December 2014 (UTC)
      You're probably right that obtaining a research grant and concrete data is the only way that the community will accept this. I might be able to collaborate on such a grant, but I wouldn't want to spearhead it. As far as this proposal, I likewise doubt that it will succeed, but we might get some interesting comments if we leave it open. —Remember the dot (talk) 21:17, 5 December 2014 (UTC)
  • Opposed to turning anything like this on by default. I don't need or want this feature; if others do that's fine, but let them turn it on themselves. I don't want this or other similar add-ons suddenly appearing by surprise and disrupting my volunteer work here. Townlake (talk) 04:58, 5 December 2014 (UTC)
  • Opposed I used this for a while and it was problematically slow on very large pages which I deal with often. Chillum 18:52, 5 December 2014 (UTC)
    The syntax highlighter automatically disables itself if it takes more than 100ms to execute, and that value is customizable. Maybe you'd like to suggest a lower default timeout? —Remember the dot (talk) 20:13, 5 December 2014 (UTC)
  • Yes I know what I was running. There are a lot of OS/browser combos on different hardware, it is going to vary in behavior. Javascript is far from predictable across browsers. Chillum 05:07, 8 December 2014 (UTC)
No it doesn't. Are you serious? Put yourself in the position of someone who has no idea what it is, and seriously think if that picture explains anything. I still have no idea what it is and what use it would be to me. New systems are needed if there are problems with existing ones. This looks more like an incomprehensible, really crappy solution to a non-existent problem. HiLo48 (talk) 21:23, 5 December 2014 (UTC)
I've now added a link to Syntax highlighting at the beginning of the documentation so that anyone unfamiliar with the concept will be able to more easily familiarize themselves with it. —Remember the dot (talk) 23:02, 5 December 2014 (UTC)
It would be better to try to explain it right there in clear, simple language. "...makes syntax stand out colorfully in the edit box" seems simple, but it's not clear. HiLo48 (talk) 21:20, 6 December 2014 (UTC)
I sort of agree. A picture is worth something and undoubtedly HiLo is able to see from the image that what we're talking about here is the wiki markup of ref, infobox, wikilink etc. However, from Piotrus's opening statement I couldn't guess that--I thought he was talking about the syntax of English. Remember the dot, I am sure you can explain in a sentence or two what this tool does; doing so will help your case. For now, I'm totally with Chillum; even loading the Twinkle menu is already slowing me down to the point where I'm even more than normally irritated. Drmies (talk) 03:09, 7 December 2014 (UTC)
@Drmies: I am certainly conscious of loading speeds, which is why I wouldn't suggest to make wikiEd a default tool (it lags terribly for me). Syntax highligher, however, has (both for me and my students) been a lag-free add-on, it loads in much less than a second - I'd say instantly - on any edit page I've tried and observed (on a number of computers). Have you experienced any lagging caused by it? --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:43, 8 December 2014 (UTC)
@HiLo48: Is the current description page better formatted? If it is still inadequate, what further improvements would you suggest - and can you point to a gadget or feature that you think has a "best practices" description page? --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:43, 8 December 2014 (UTC)
  • Oppose If we're still discussing things like reasonable default timeout values, then it's not ready to be turned on by default (and I'm actually concerned about the timeout anyway: will some editors experience seemingly random behavior where the feature sometimes works and sometimes doesn't depending on invisible factors that impact loading time?). I also have a more personal aesthetic objection: I prefer more traditional syntax highlighting where the tokens themselves are given a different style rather than changing the background. Changing text background introduces much more visual weight and clutter. I'm guessing this approach is due to a technical restriction, given that it is the only style option available. Regards, Orange Suede Sofa (talk) 21:18, 5 December 2014 (UTC)
    It's not seemingly random; if you've ever had this happen to you, you will have noticed the message that appears to explain why syntax highlighting isn't available. And yes, the background-highlighting approach is because of technical restrictions. —Remember the dot (talk) 21:30, 5 December 2014 (UTC)
  • Oppose for now, generally on account of issues, possibly including performance, but I am open to reconsidering if a better case can be made. If seems very useful despite its warts then perhaps prominent suggestion can be made on how to enable it. ~ J. Johnson (JJ) (talk) 21:15, 6 December 2014 (UTC)
  • Comment - I would just like to say how much I enjoy using the syntax highlighter tool. I am a poor typist, and I find it invaluable in finding mismatched brackets, etc. If it can't be a default tool, perhaps there is a way to advertise it to new users, since it appears that there are some who don't know of its existence. If I were an IE user, this tool would be enough to make me switch.—Anne Delong (talk) 22:54, 6 December 2014 (UTC)
    If you love it, maybe you can help others by explaining it in better words than "I've created a script that makes syntax stand out colorfully in the edit box". I'm still unclear on what it does and why it's useful. HiLo48 (talk) 23:08, 6 December 2014 (UTC)
    @HiLo48: It makes editing pages easier, because it's easier to find specific bits of markup that would normally be lost in a sea of text (this is what it feels like to me, anyway, particularly when editing larger articles). Using this gadget, markup gets highlighted in groups so you can differentiate between templates, wikilinks, formatting, HTML, and actual prose. I, JethroBT drop me a line 23:28, 6 December 2014 (UTC)
    Thanks. That's a lot clearer. HiLo48 (talk) 03:08, 7 December 2014 (UTC)
    Don't believe him, HiLo--that's just what a bot would say. Skynet, anyone? Seriously, I'm still waiting, as are others, on a good sales pitch. Obvious syntax issues aren't problematic; it's the tricky ones that are bothersome, like the stupid syntax for tables. I remember it once took three editors and an hour or so to figure out that it was an errant hard return that fucked up an infobox. Does it spot that? Drmies (talk) 03:12, 7 December 2014 (UTC)
    Although the more obvious syntax errors may not be as hard to find as the example you give, they occur much more frequently, and each one eats up a little time. The syntax highlighter makes it obvious, even to people like me with rather poor eyesight, when there are mismatched apostrophes, or when a square bracket has snuck in where a curly one was intended. —Anne Delong (talk) 12:28, 7 December 2014 (UTC)
    Actually, that's a really good example (the brackets) of something that bothers me as well--old age. But I wouldn't want another piece of interface in between with, as I expect, a relatively low payoff. YMMV, of course. Drmies (talk) 15:20, 7 December 2014 (UTC)
    @HiLo48: For me, the major advantage for new editors is that it allows them to find editable prose text easily, without having to parse through code, which can be daunting for the newbies (particularly when it comes to references or tables). Advanced editors should also benefit from the ability to quickly distinguish code from prose due to the visible background changes. --Piotr Konieczny aka Prokonsul Piotrus| reply here 04:43, 8 December 2014 (UTC)
    Anne, I think you have a good idea here: we need a good way to "advertise" gadgets and tools to editors, so that people can find the tools that they would benefit from (without having to go through dozens of items in prefs). WhatamIdoing (talk) 21:59, 8 December 2014 (UTC)
  • Couldn't the syntax highlighter be turned on and off by a toggle in the edit toolbar ? It would be off by default and the toggle wouldn't even be displayed in browsers where it couldn't work. If possible, it should remember if it's been turned on or off from one edit to the next (otherwise, add an option in preferences to turn it on by default, but it wouldn't be as handy). This way it wouldn't bother anyone not interested in it but would be readily accessible for anyone who may be interested. Cenarium (talk) 04:06, 7 December 2014 (UTC)
  • I really like this tool and used it for a while but turned it off because I do a lot of work where I open numerous pages at the same time (using multi-links) and when doing so using the Syntax highlighter the loading takes a really long time, and with it failing pretty much across the board.--Fuhghettaboutit (talk) 15:30, 7 December 2014 (UTC)
  • Thanks for the feedback. I just modified the code to improve its load time, so hopefully it will fail less often now. Honestly though, I'm a bit surprised that so many people are now complaining of performance limitations because the script rarely times out on me, even on my phone. —Remember the dot (talk) 04:27, 8 December 2014 (UTC)
    I've also had very few timeout issues. I, JethroBT drop me a line 04:33, 8 December 2014 (UTC)
  • Oppose - I've never used the tool and sure as hell don't plan on using it any time soon. –Davey2010 • (talk) 04:50, 8 December 2014 (UTC)
  • Oppose it as a default. I sure wouldn't want a load of highlighting to interfere with the readability of an edit window, and I'm still unsure, after reading the posts above and looking at that picture, what the heck it's supposed to tell us. What 'syntax' is referred to - grammatical, programming or what? If it's to do with the grammar, no way. I'd be happy with a spellchecker that could lightly mark 'form' when it should be 'from' (and so on and so froth), but that's very unlikely to ever happen. I think we'd find that a lot of people would just ignore the highlighting because they wouldn't know what it was for. Or what to do about it. If it's to do with coding, even fewer will know what it means. It may be fine for those that want it, but don't try to force it like the WMF do so often. Peridon (talk) 18:12, 10 December 2014 (UTC)
Looks like it is coding. Is it for 'geek level' coding, or 'page editing level' coding? Peridon (talk) 18:20, 10 December 2014 (UTC)
Note I am not opposing the existence if this tool. I have no objection to other people using it. I do object very strongly to it being foisted on all and sundry, mopst of whom won't know what it is and won't know how to turn it off. Obviously, people have already discovered it and some like it. Good for them. But enough with the defaults... Peridon (talk) 19:56, 10 December 2014 (UTC)
  • Support: I've started to use the syntax highlighter for the first time since seeing this discussion: it's brilliant. I was editing an article where the original editor had put punctuation after refs instead of before: the highlighter coloured the refs so it was much easier to skip to the end of a group of two or three adjacent refs, spot the punctuation, move it to the right place. I'll be using it regularly now. It's timed out on me once so far, but produced an obvious, and comprehensible, notice to say so. I think it might well be helpful if it was a default: the colouring clearly indicates something, and by looking at it you can see what. Without the colour, a very new editor is much more likely to accidentally edit within a reference or otherwise get in a mess. I can't see that it would do any harm to anyone. Having started this message off as "Comment", I've talked myself into changing that to "Support". Failing that, as Anne says, we need a better mechanism for telling people about the useful gadgets, rather than expecting new editors to browse the "gadgets" tab in "preferences" and work out for themselves how useful something will be. PamD 18:33, 10 December 2014 (UTC)
I agree that there should be a Glossary of Gadgets or some other name, linked from the gadgets page (and the welcome templates too, perhaps, telling people that there are gadgets there if they want them) to tell people what the gadgets do. If there was one, it would have saved me having to be a bit scathing on VPT about things that changed with only the techies knowing and understanding. Peridon (talk) 20:03, 10 December 2014 (UTC)
@Peridon: I proposed something like that (with a wireframe mockup) at mw:Talk:Requests for comment/Redesign user preferences#Gadgets. +1 it if ya like it. Quiddity (talk) 01:51, 17 December 2014 (UTC)
I'll try to look tomorrow. Currently tired and hungry... Peridon (talk) 00:03, 18 December 2014 (UTC)
To be quite honest, I can't see much difference. Adding the number of users would put me off some things, as I'm one of those who tends to think that large numbers of people can be wrong (they buy FIATs, don't they?). I'll try again later. Peridon (talk) 19:39, 18 December 2014 (UTC)
  • Opposed ( was support ) Being able to see where the beginning and ending of bolding quotes ''' and other markup is very useful especially for new editors that might not yet be used to counting brackets etc. PaleAqua (talk) 18:43, 10 December 2014 (UTC)
    Switching to opposed. The performance impact on mobile editing is too large. Having had to do a bit of mobile editing this week the performance has really slowed me down. PaleAqua (talk) 23:39, 20 December 2014 (UTC)

During XFDs, it can be helpful to see what a page looked like when the discussion began, especially if it's been heavily edited since that time. I'd like to see all of the XFD headers include a link to the page as of when the XFD discussion was created; for example, this would be in {{afd2}} and {{cfr2}}. Is this possible? I'm talking about an autogenerated link dependent on some sort of timestamp, vaguely comparable to the timestamp that's given when we add {{prod}} or {{db-c1}} to a page. No point in discussing adding this if it won't work. Nyttend (talk) 02:32, 17 December 2014 (UTC)

This could easily could be added to a tool such as Twinkle. However, I don't think it would be possible for those who don't use scripts and gadgets, without making people manually fetch the oldid (revision ID) of the current revision of the page when they nominate it. Lua doesn't seem capable of fetching oldids. — This, that and the other (talk) 05:13, 17 December 2014 (UTC)
I think it should be possible within the wikitext. Would the following work?
  1. Make the deletion tags added to the article ({{Afd}} etc.) add a parameter such as |revision={{subst:REVISIONID}}
  2. Use Lua to retrieve the revision number from the article source (e.g. with a regex .*$|revision=($d+)$}$}.*)
SiBr4 (talk) 10:54, 17 December 2014 (UTC)
Sounds good, if technically practical to do automatically. עוד מישהו Od Mishehu 07:29, 21 December 2014 (UTC)

Posted at Wikipedia talk:Twinkle, I asked those editors to comment here. Oiyarbepsy (talk) 06:10, 22 December 2014 (UTC)

Sounds brilliant (if possible). This way if the article has been greatly improved since the AfD began, it avoids making the proposer look like in idiot, and if it's been "gutted" then it gives "Keep"-ers something to work with. — Preceding unsigned comment added by Eman235 (talk • contribs) 13:31, December 22, 2014‎

Community authority over admins

There have been a lot of de-sysop proposals around here lately. I am coming here with my suggestion on how to make sure admins are more accountable to the community without making drastic changes to policy.

I will start by pointing out what current policy already allows:

  1. The community can come to a consensus that a person be blocked, including an admin
  2. The community can come to a consensus that a person be given an interaction ban, including an admin
  3. The community can come to a consensus that a person be given a topic ban, including an admin
  4. The community can come to a consensus that a person be banned outright from Wikipedia, including an admin.

This is all true right now. There is however a culture that admins are not to be blocked or sanctioned, while this attitude is prevalent it does not enjoy consensus. I think the community needs to show some teeth and actually propose and come to consensus to do these things when it is needed.

So far this is not a policy change proposal but rather a plea that users who think admins are not accountable use the authority the community already has.

I do want to propose one addition to policy:

  • If the community comes to a consensus to ban and administrator from Wikipedia then that administer shall have their admin bit removed "under a cloud".

Existing policy allows the community to hold admins accountable. If an admin is harassing a user, IBAN that admin. If an admin is poorly closing AfDs regularly then topic ban that admin. If an admin is acting downright poorly then block that admin for whatever length of time you see fit. BAN that admin if the issue is serious enough and you can get consensus.

I am saying all of this as an admin, and I will challenge any admin who thinks that community sanctions are not applicable to them. The community is failing to use the authority they already have, lets try using it before trying to get more.

I propose the one policy addition only to satisfy those we think we need community desysoping. Really it is redundant as if an admin unblock themselves they will lose their bit for sure. I could care less if the addition is made but I do feel strongly that the community needs to be more assertive with what they already have. Chillum 04:00, 22 December 2014 (UTC)

The wording, as drafted, seems to me unclear as to whether it applies to bans in general or only full bans (as bans can be IBANs and topic bans and whatnot). I'm also not sure that it is wise to link so strictly the two things. That is not to say that admins should not be accountable to the community, but merely that there could be cases where the community should have the option of not desysopping a person when a ban is issued. Snowolf How can I help? 04:05, 22 December 2014 (UTC)
I agree with your point. I think it is redundant too, I added it to appease those who insist on community desysoping. It makes no different if you desysop someone who is banned anyways.
This is more of a plea that the culture change to be less afraid and use the authority they already have. Chillum 04:16, 22 December 2014 (UTC)
I obviously agree that the community already has ample authority and powers to police their admins and can do so as it deems fit. Sysops are not special users, and are subject to all policies just as normal users, and they can be restricted just as normal users, regardless of their hats, including obviously being advised not to use their hats in any or all ways. We, as administrators can operate merely with the consent and authority of the English Wikipedia community, and should we loose its confidence, we have to accept that and act accordingly. Snowolf How can I help? 04:19, 22 December 2014 (UTC)
(edit conflict × 2) I'm planning on winding down my participation in these matters for a little while, but I have a very important question. Why is it that people don't make a big deal out of the community's ability to impose something as draconian as a ban, while they're nervous about letting the community have an easy desysopping procedure? In my opinion, simple desysopping is a much less severe "punishment" (so to speak) than an all-out site ban. As I've said before, there are times when an admin is far from deserving a ban, but is just not fit to have the admin toolkit. A desysopping procedure independent of bans is needed. Otherwise, we'll have unwanted cascading effects. --Biblioworm 04:21, 22 December 2014 (UTC)
The community, as I understand it, can impose a targeted ban to prevent an administrator from using their powers. There's no need for any restriction on a user's editing, if the concern is merely with their administrative actions. There are many kinds of ban that are not an all-out site ban :) To answer your question as to why procedures for the community removal of administrative privileges struggle to be supported, I think that might have a lot to do with specifics more than the concept in general. I think more editors think that admins should be accountable to the community, but the best way to do so can be difficult to agree upon :) Different people have different concerns about different methods of proceeding with removals, I think. Snowolf How can I help? 05:32, 22 December 2014 (UTC)
Well, then, if the community can essentially ban admins from using any of their tools, why can't that same ease be applied to desysopping? Or, perhaps, we could institute a system where the community impose "targeted bans", as you put it, and the admin is automatically desysopped if the ban is ever violated. --Biblioworm 16:20, 22 December 2014 (UTC)
Any user will end up blocked if they violate their ban. If an admin unblocks themselves then they will lose the bit. If your goal is to make admins accountable and to have the community exert authority over them then existing powers are enough. If that is not enough and you need to remove the bit too then ask yourself why? Are you seeking accountability or penalty? Chillum 18:25, 22 December 2014 (UTC)
I have no objections for full-banned admins being desysoped - after all, if theyt can't even be trusted to edit, how can they possibly be trusted to do administritive actions? However, TBAN and IBAN shouldn't apply here - the admin can probably still be trusted to take administritive actions outside ther ban. עוד מישהו Od Mishehu 08:07, 23 December 2014 (UTC)

I don't understand Chillum's proposal. My opinion is that if the community is allowed to decide any kind of ban, it must be based on a violation of an previous rule (uncivility, abuse of powers, etc). That is, I disagree with the community banning a user just because of a vote. --NaBUru38 (talk) 15:25, 24 December 2014 (UTC)

Question: It's asserted that "The community can come to a consensus that a person be blocked, including an admin", etc. How? The RFC/U process, which allowed for a fairly deliberate discussion, has just been eliminated. wp:ANI's focus is not on reviewing a person's impacts in depth; the focus is on shutting down incidents quickly and there is delight in applying "boomerang" to anyone--especially non-admins--suggesting seriously any action about an admin. There's no concern for fairness, and no deliberate process. wp:3RR in practice is also dominated by quick judgment with no concern for fairly identifying fault. ARBCOM is not a venue for the community to decide something, it is set up for arbitrators to exercise their arbitrary power to arbitrarily settle something (and has its purposes). What venue for the "community" to discuss and come to a consensus about an administrator, is available? I don't see how the community has any such powers that are asserted. --doncram 22:09, 24 December 2014 (UTC)

? RFC/U by design could not take any action. Community banning occurs at AN and sometimes AN/I and has for a very long time. Alanscottwalker (talk) 22:42, 24 December 2014 (UTC)
RFC/U could discuss patterns of behavior, deliberatively, and can develop a consensus. Yes technically there was not power to de-sysop or block someone. RFC/U could be opened by non-admins and be more of a general community thing, in my view, than wp:AN and wp:ANI can be (where yes a non-admin can open something, too). At ANI just now there developed a consensus to ban some editor involving paid editing, but the issue was a current dispute, which is what ANI is more tuned to address than reviewing an editor. AN and ANI are obviously often unfair and non-deliberative, being over-run by drive-bys and by people who like disputes and who delight in boomerangs or dysfunctional in many ways you and I have seen described, and AN or ANI do not seem suited to the development of community consensus that is posed as having power in the opening of this discussion. Sure sometimes a crazy mob is whipped up in a seeming crisis and someone decides the consensus is to ban, at ANI or AN. And that is often highly random and unfair, coming down harshly on one person for a rule violation when that consequence is not applied to others, especially not to admins who violate rules and who participate actively in ANI and AN. I don't believe there is a venue working to consensus of the community in the way that is supposed in the beginning of this discussion. --doncram 19:50, 26 December 2014 (UTC)

MediaViewer RfC questions

Moved to Wikipedia:Village pump (proposals)/Media viewer 2014

— {{U|Technical 13}} (e • t • c) 01:50, 30 December 2014 (UTC)

Restrict title blacklist override and no rate limit to account creation for account creators

There is a clear consensus to replace tboverride with tboverride-account and noratelimit with noratelimit-account in the account creator permission. Armbrust The Homunculus 18:13, 30 December 2014 (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.

The account creator usergroup was given title blacklist override (tboverride) in order to create accounts matching the title blacklist, but the userright allows to override the title blacklist everywhere, so also for moves, pages creations and editing of title blacklist protected pages (used for editnotices, TFAs, etc). A userright allowing override only for account creations (tboverride-account) was created a few years ago, but we didn't switch back then because there was some purpose in allowing selected non-admins to edit those. Now, we have the template editor usergroup, specifically designed for this purpose, so there is no longer any need for it. And account creator is granted increasingly easily to any user who claims to need it for an event or meetup, without regard to experience; this wouldn't be a problem in itself, but this creates a pointless security risk. So we should grant them tboverride-account instead of tboverride. The same goes for the userright bypassing rate limits (noratelimit), which allows to create more than six accounts per 24 hours but also makes page moves unlimited, etc. We could request switching to a userright allowing bypass only for account creations. Cenarium (talk) 13:48, 27 November 2014 (UTC)
PS : Restricting no rate limit will also allow us to give more rate limited rights to all autoconfirmed users without taking big risks, such as a rate limited move subpages userright. Cenarium (talk) 14:19, 27 November 2014 (UTC)

Personally, I don't see the point. If people abuse the right, then it should be removed. I think granting them the full lot is a net positive, as it allows them to carry out this work. Unless we are going to make another group to allow people to bypass the blacklist to create pages etc., why reduce the pool of people who can do this? --Mdann52talk to me! 14:04, 27 November 2014 (UTC)
I agree with the blacklist bit, but not the rate limit. Reason why? If the bit is abused, it's removed. Since we already have an account specific flag, I see no reason not to use it. However, creating a flag creates some unnecessary technical work, depending on the mood of the devs. What I see more viable is adding a technical featuring that places a time limit on the bit, and automatically removes it after the time limit expires. That would definitely work for account creator bits.—cyberpower OfflineHappy Thanksgiving 14:09, 27 November 2014 (UTC)
@Mdann We already have that other group now, template editor, which is why I'm suggesting it now. Account creators only use their rights for account creation.
@cyberpower This will also allow us to give more rate limited rights such as a rate limited move subpages feature without taking any additional risk. It's what prompted me to look into this, actually. Cenarium (talk) 14:19, 27 November 2014 (UTC)

I'm confused. I understand tboverride, but I don't understand what tboverride-account is. Could you explain better? Oiyarbepsy (talk) 20:20, 28 November 2014 (UTC)

It allows to override the title blacklist when creating an account (some abusive account names are blacklisted), and only when creating an account. Cenarium (talk) 20:48, 28 November 2014 (UTC)

Temporary granting

Since this is used by a lot of class supervisors and the like, it is technically feasible to grant it for a limited period? Oiyarbepsy (talk) 20:20, 28 November 2014 (UTC)

Unlikely to be technically feasible anytime soon, see T12493. Cenarium (talk) 20:48, 28 November 2014 (UTC)

Phase 1

Tracked in Phabricator
Task T76050

I think we certainly can deal with this in a step-wise fashion, without having to have new permissions set built. We frequently run across short term account creator requests at WP:PERM (for workshops, etc) and usually issue them with strong warning to only use that permission for account creation and not to override the blacklist for other reasons, or else. — xaosflux Talk 15:52, 28 November 2014 (UTC)

Change proposed
CHANGE enwiki "Account creators" group permissions as follows:
REMOVE tboverride
ADD tboverride-account (c.f. mw:Extension:TitleBlacklist)
Support
  1. As phase proposer, — xaosflux Talk 15:50, 28 November 2014 (UTC)
  2. Per above. FYI, I had already filed the bug and was asked to start a discussion - T76050. Cenarium (talk) 20:11, 28 November 2014 (UTC)
  3. Yes. Yes yes yes. I've been wanting this for literally years. I was unaware this right now existed, or I'd have pushed for this a while ago. [stwalkerster|talk] 01:41, 29 November 2014 (UTC)
  4. Absolutely - This right is designated for creation of new accounts; we should only grant them the rights necessary to create these accounts. de>tboverride-account gives them as jkuch of the ability to do this task as tboverride does, but aloows them to do less other restrcted stuff, so ot's better for this group. עוד מישהו Od Mishehu 19:24, 29 November 2014 (UTC)
  5. Support Sounds like a great idea, wish we were aware of it in the previous discussions about the user group. Callanecc (talk • contribs • logs) 06:26, 4 December 2014 (UTC)
  6. Support Seems very reasonable to me. tboverride-account is what account creators require, not tboverride. Tony Tan98 · talk 15:23, 7 December 2014 (UTC)
  7. Support. Very reasonable change. APerson (talk!) 05:09, 8 December 2014 (UTC)
  8. Support Sounds reasonable, and the right is already implemented, so why not? FunPika 20:27, 14 December 2014 (UTC)
  9. Support Seems to make sense. Always found it strange that Account Creator rights came with all the extra seemingly unrelated stuff. Sam Walton (talk) 23:22, 14 December 2014 (UTC)
  10. Support Mike V • Talk 00:09, 15 December 2014 (UTC)
  11. Support -Sounds reasonable. I didn't knew however, that an account-creator was able to do that much stuffs. Out of interest, Has the possible abuses mentioned in the discussion above ever been practiced in real yet by any account-creator? Anupmehra -Let's talk! 09:32, 15 December 2014 (UTC)
  12. Support If we didn't already have the correct userright I'd probably oppose as unnecessary, but since it's all in place, we might as well change it. Gigs (talk) 17:13, 15 December 2014 (UTC)
  13. Support Chris Troutman (talk) 22:13, 15 December 2014 (UTC)
  14. Support this group is for creating accounts and not anything else. A reasonable change. BethNaught (talk) 22:27, 15 December 2014 (UTC)
  15. Support - Mlpearc (open channel) 17:58, 17 December 2014 (UTC)
Oppose
Comment
This is on phab, at phab:T76050. — Revi 06:17, 29 November 2014 (UTC)
100% support a month in, can someone close this so we can update Phab to show community support? — xaosflux Talk 03:20, 29 December 2014 (UTC)

Phase 2

About the rate limits (maximum of page moves or other actions allowed per minute or some other duration). noratelimit allows to bypass all those rate limits, as well as the limit of 6 account creations per 24 hours period.

Tracked in Phabricator
Task T76053
Change proposed
CREATE noratelimit-account enabling to bypass the limit on account creations only
CHANGE enwiki "Account creators" group permissions as follows:
REMOVE noratelimit
ADD noratelimit-account (c.f. mw:Manual:$wgAccountCreationThrottle)
Support
  1. So that we can unbundle from sysop or create more rate-limited rights without taking unnecessary risks, such as a rate limited subpage moves. This right was initially given to all autoconfirmed users but had to be restricted to sysops because it didn't respect the rate limits so was massively abused for page move vandalism, I've proposed to modify it so that it does respect the rate limits, making it safe to give back to autoconfirmed users ... unless some of them can easily get assigned a noratelimit userright. Yes, we're restricting a bit here, but those users aren't supposed to use it outside account creations anyway, and it allows to open up elsewhere. Cenarium (talk) 20:11, 28 November 2014 (UTC)
    I don't really understand what you are saying here. Are you also proposing a change in the way noratelimit works? Gigs (talk) 17:17, 15 December 2014 (UTC)
    Yes, but it is separate from this proposal (autoconfirmed users would have the ability to move subpages but subpage moves would count in the rate limit - so no more than ten per minute in total). My point is that it will allow us to grant account creator usergroup to any and all users who need it, without having to worry about rate limits and especially future modifications in the way noratelimit works. Cenarium (talk) 10:47, 19 December 2014 (UTC)
  2. Definitely, the proposed user right would give this group the full account-creating ability that noratelimit gives them. עוד מישהו Od Mishehu 19:26, 29 November 2014 (UTC)
  3. Support this one two, all the group to do what it should be able to do. Then we can look into giving the right to other groups. Callanecc (talk • contribs • logs) 06:29, 4 December 2014 (UTC)
  4. Support as well, because this does not remove any account-creation abilities and account creators do not need to override all rate limits. Tony Tan98 · talk 15:29, 7 December 2014 (UTC)
  5. Support Account creators don't need to be able to override rate limits on anything but account creation. FunPika 20:45, 14 December 2014 (UTC)
  6. Support Again seems sensible. Sam Walton (talk) 23:24, 14 December 2014 (UTC)
  7. Support Mike V • Talk 00:10, 15 December 2014 (UTC)
  8. Support -Yes, otherwise we have to rename the group to overriders, if it is not limited to only accounts. jk Anupmehra -Let's talk! 09:32, 15 December 2014 (UTC)
  9. Support Chris Troutman (talk) 22:13, 15 December 2014 (UTC)
  10. Support BethNaught (talk) 22:27, 15 December 2014 (UTC)
  11. Support It's a bit of process creep, but if the devs are fine with it so am I. — xaosflux Talk 22:38, 15 December 2014 (UTC)
  12. Support - Mlpearc (open channel) 17:59, 17 December 2014 (UTC)
Oppose
Comment

FYI, this need new phab bug, other than the one in Phase 1. (When creating new one, please CC "Revi" so I can tag it or do the patch.) — Revi 06:22, 29 November 2014 (UTC)

There is currently a bug open (T50373) for merging $wgAccountCreationThrottle into $wgRateLimits. If this happens I believe it would be possible to modify the $wgRateLimits configuration to remove (or at least set to an impossible to hit level) the account creation limit for the account creators group. Therefore we shouldn't need a new right. FunPika 03:26, 15 December 2014 (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.

Implementation

I've opened phabricator:T85538 to request that this be done here. The tboverride change is ready to be done now, but the noratelimit change requires resolution of phabricator:T50373 to happen first. Jackmcbarn (talk) 18:23, 30 December 2014 (UTC)

Conduct a new "new editors" test of VE

The precise way this test will be conducted is TBD. this means how will it be executed, and what will be the metrics of success/failure. i think similar test was run in the past, either here on enwiki or elsewhere. if memory serves, this is sometime referred to as "A/B test".

I opened a discussion in WP:VPT recently suggesting exactly this, and asking the community for comments. several people responded with "oppose", but as far as i could understand their arguments, they were mainly of the types "MWF sould never have done it - there are better ways to spend development resources", and "I do not like/hate VE, so i will oppose anything related to it".

I could only find a single viable argument: the use of VE by some editors cause many wrong "nowiki" to appear in the wikicode, which causes damage.

as luck would have it, the latest code version (came out after the discussion started) fixes the "nowiki" problem.

i think VE made enough improvement in the (almost) year and a half since WMF tried to force us to use a half-baked product. i think VE is ready now for a new round of testing. once we get some stats, we can decide if we want to ask for some specific changes and improvement, or are we ready to enable VE again. peace - קיפודנחש (aka kipod) (talk) 21:16, 13 December 2014 (UTC)

If this is done in a way that forces new editors to use it, then I will have to vote against this. If it is given as an option, then I might be for this. Tharthandorf Aquanashi (talk) 00:03, 15 December 2014 (UTC)
there is no "forcing" anyone to use it. even on wikis where it's no experiment, and is activated by default for everyone, it's always an option: every editor still has "edit source" (i.e., activate the current wikitext editor) on every editable page. peace - קיפודנחש (aka kipod) (talk) 01:17, 15 December 2014 (UTC)
It's quite possible such tests have been done throughout the development of VE, by the development team. That should be intuitive to any competent team, and I have no reason to believe that the VE team is not competent. In any case, if they haven't been doing that, they should be the ones to do it, and the suggestion should be made there, not here. ‑‑Mandruss ☎ 01:25, 15 December 2014 (UTC)
the tests (aka A/B test) were done on numerous wikis, ttbomk including enwiki, and the conclusion was to activate VE. after activating VE (and making it the default for anons), the enwiki community revolted, and after some unpleasant discussions with VE team, we turned it off (to the best of my knowledge, we and dewiki are the only projects that did that - i might be wrong here). i doubt WMF will conduct a new test on enwiki without the community's permission, so you can read this proposal as "allow WMF to conduct VE test on enwiki again". peace - קיפודנחש (aka kipod) (talk) 17:40, 15 December 2014 (UTC)

A few comments:

  • VisualEditor is available almost everywhere, either as an option or as by default.
    • VisualEditor is enabled by default for all users (logged-in and logged-out) at about half of the Wikipedias, at MediaWiki.org, and a few other smaller projects.
    • At Wiktionary (except sv and fr; Wiktionary is exceedingly template-heavy) and Wikisource (needs integration with ProofreadPage), it is not available at all.
    • At all others, you have to enable it in the Beta Features tab of Special:Preferences.
  • VisualEditor is not offered by default to about half of the Wikipedias because of language problems. Some (e.g., Welsh) need a more robust special character inserter. Some (e.g., Japanese) need special language support. Some (e.g., Chinese) need really complicated language support.
  • VisualEditor is additionally not offered by default (you can opt-in if you want) at four large Wikipedias:
    • Dutch, where it was never enabled by default, because of template-related problems;
    • German, where it was never enabled by default, because of a community request to wait for further features, like table editing;
    • English, where it was turned off in September 2013, because of community frustration with wikitext corruptions; and
    • Spanish, where it was turned off a few months later.
  • It might be possible to set up another round of A/B testing with new editors here. I'd have to ask, and Analytics is frankly overloaded, so I can't guarantee anything. This would probably involve making VisualEditor be enabled by default (i.e., they get immediate access to both editors) for 50% of new user accounts for maybe a week, and then following all accounts for a few weeks, and seeing if any differences appear (e.g., if new editors with access to VisualEditor are more or less likely to edit on a second day than editors without immediate access to it). (Note that the length of the trial would should be determined by the stats people, with the goal of producing a statistically significant result. That might not be exactly one week, but I think (based on comments they've made in the past) that 50% of newly registered accounts at en.wp for about a week is often sufficient.)
  • The user testing that's been done more recently is more intensive, for example, video-taping new editors as they try to accomplish specific tasks. This eliminates some problems (none of their edits appear on wiki) and introduces others (none of you can see what they did or hear what they said). It has some advantages (you can ask testers direct questions about why they did something) and some disadvantages (they're not necessarily "real" editors, who have chosen an article that interests them and want to improve it). On balance, though, it seems to be useful.

If there is interest in requesting more testing, then please let me know. Whatamidoing (WMF) (talk) 03:18, 16 December 2014 (UTC)

Question: If the probably was that it was previously causing wikitext errors, then what exactly is the testing for? We should know if it's still generating errors from the registered editors that use it. So if the wikitext problems are fix, we should just enable it for everyone without testing. Oiyarbepsy (talk) 15:42, 16 December 2014 (UTC)
That was a main cause of nowiki tags among experienced editors; brand-new editors never made that mistake. There are some other problems that cause nowiki errors as well, like a stray space added when you split one paragraph into two. You can check the current status, if you want: https://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=550 This link shows nowiki tags added in both the wikitext editor and VisualEditor. The last time I did a spot-check, VisualEditor was still producing more than its fair share of nowikis, but maybe 70% of nowikis are coming from then wikitext editor. Whatamidoing (WMF) (talk) 20:59, 18 December 2014 (UTC)
See also:
No easy answers. For me, VE is getting more usable. Insert pictures, add a wikitable row, etc. If VE gets easier referencing tools, we're in business! (mw:Citoid, mw:VisualEditor/Design/Reference Dialog) And then we need to put this slooooow VE thing on steroids! --Atlasowa (talk) 15:05, 18 December 2014 (UTC)
Citoid is currently expected for January 2015. I'm not sure which project will see it first. It will be released for VisualEditor initially, but James F (the product manager) wants to add it to the wikitext editor, too. Access to fully formatted citations in two clicks would be valuable for everyone, not just for users of VisualEditor. Whatamidoing (WMF) (talk) 20:59, 18 December 2014 (UTC)
Very glad to hear that, Whatamidoing (WMF) :-) January 2015 sounds great and not forgetting wikitext refs sounds even greater! I just looked at the latest VE Reference Dialog Design and the prototype.
I have 2 suggestions to make:
1) The reference dialog "insert URL + autofill, preformatted -> done" is too dumbed down:
  • When a user clicks the cite icon in the toolbar, this dialogue pops up in context where the cursor is.
    When a user clicks the cite icon in the toolbar, this dialogue pops up in context where the cursor is.
  • The user pastes their URL into the field and clicks Done.
    The user pastes their URL into the field and clicks Done.
  • VE searches the URL and returns a formatted reference. It is shown in a tooltip here.
    VE searches the URL and returns a formatted reference. It is shown in a tooltip here.
  • After an auto-filled citation is returned, the user can choose to edit it. They enter a form in which each field is labeled. If the software cannot find a field that is required, it is marked.
    After an auto-filled citation is returned, the user can choose to edit it. They enter a form in which each field is labeled. If the software cannot find a field that is required, it is marked.
  • The user can also choose to enter the citation manually. Here they can select the type of citation.
    The user can also choose to enter the citation manually. Here they can select the type of citation.
  • The user has selected cite web, and enters the form.
    The user has selected cite web, and enters the form.
We want editors to check / correct the autofilled ref, but you currently need an extra-click "edit" to be able to do that ("the user can choose to edit it"). I don't expect the citoid autofill to work perfectly for every URL, nobody can expect that. The form for editing the ref should be shown by default, not hidden behind extra-clicks. As the VE ref dialog works currently, it invites lazy unchecked autofill-refs. Show the autofill-ref in a form! Have a look at makeref and templator by magnusmanske, these tools do this well (blue-framed fields are mandatory, white ones optional; please fill out as many as possible).
icon to insert reference: The 3rd one is obvious and preferred! Not the brick factory icon (first)!
2) The ref icon (insert reference). It is very unintuitive. This has been pointed out over and over and over again.
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback#Icons_are_incomprehensible
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Reference_Issues:_Omnibus_Edition
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Mystery_meat_navigation
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#References
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Attempting_to_add_a_reference
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#User_experience
http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_07#Refs_and_templates
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_8#Icons_are_incomprehensible
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2013_12#Editing_a_footnote
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Toolbar#Icon_for_Reference
https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Feedback/Archive_2014_1#The_new_reference_dialogue
There is even a bugreport for the ref icon, which was "provisionally closed". And we're still stuck with the incomprehensible brick factory icon, which some WMF designers seem to prefer. I think the "ref [1]" is a lot better to understand. And yes, make [1] blue if this gets us better references, damn the design guidelines! But, who decides this?
How about this: Let's make a survey with 3 alternatives. Or not really a survey, rather a banner with user test, for potential new users, aka readers and editors. Show them the editbar full of icons (including the 3 ref icon options) and ask them to insert a reference, count which icon they click. Bonus: This test/survey would also work as a tutorial / invitation to edit (some time, not immediately) / participation tool / VE announcement. Win-win? --Atlasowa (talk) 12:47, 19 December 2014 (UTC)
On 1), I believe that the design is supposed to automatically show the entire citation (look at the third image) as it will display to the reader. In terms of getting people to check the ref, this is probably more effective than showing them a screenful of filled-in boxes, with no idea how the data in those boxes will be used. In my own testing (which has focused on PubMed and Google Books), the accuracy has been remarkably good, and sending me to an editing panel would not have been as useful as showing me the finished output.
On 2), the desktop site does not use those icons; the cite menu is identified with the word "Cite" (or the local language equivalent). There are some appearance changes on the way. You can see them at MediaWiki.org now. (Type something at the bottom of the sandbox to see the 'Save' button's new color.) None of the changes involve replacing the "Cite" label with the book/bookmark icon. Whatamidoing (WMF) (talk) 19:52, 19 December 2014 (UTC)
On 1) Citoid UI: Go use the citation dialog with real URL refs from random WP articles, not "focused on PubMed and Google Books". "showing the finished output" is not "getting people to check the ref", it is getting people to lazily insert whatever the software autofills. You're making a big mistake if you do no real-world testing, invite lazy unchecked autofill-refs and wait for another community-shitstorm. Citoid is a great thing, please do not fuck it up.
On 2) insert ref icon: Whatamidoing (WMF), your response is false, or at least very misleading. You pretend that the brick-factory ref icon is not used. Go to https://en.m.wikipedia.org/wiki/Flotation#/editor/0 you see the brick-factory ref icon! Or go to MediaWiki.org VE editing, click on "cite", what do you see: the brick-factory ref icon! Go to the latest VE prototype, what do you see: the brick-factory ref icon! You write "There are some appearance changes on the way" - will they remove the brick-factory ref icon, on desktop AND mobile, yes or no? Please do not dismiss the suggestion by pretending that the icon is not used, only to have the brick-factory ref icon all over the place in the coming months. Read the bugs closing comment "I'm going to provisionally deem this solved with the new icon." --Atlasowa (talk) 17:03, 21 December 2014 (UTC)
  1. My testing exclusively involves whatever sources I'm actually using in my everyday volunteer editing. I tend to use books and journal articles rather than random websites. Using the tool while actually writing encyclopedia articles presumably counts as "real-world testing" by most standards. Beyond that, I'm not the QA team, so it's not my job to do systematic testing. In theory, the product isn't ready for that type of testing yet (which is what I'm told every time the service goes offline while I'm writing).
  2. I do not understand why putting the entire, fully formatted citation in front of people is going to make them less likely to check the citation than putting a small fraction of the template's parameters and data in front of them. You are asking us to show all editors this. Notice that the screenshot displays just three parameters out of the eight in this example (it could be many, many more). The plan is to show editors the entire citation:
    • Fitzgerald, Carol (2001). The Rivers of America: A Descriptive Bibliography. Washington, D.C.: Oak Knoll Press. p. 199. ISBN 9781584560326.
    If there were an error in this citation, then which of these two displays do you think would make it more likely that the editor will see it? The one that shows you all the information, including formatting, or the one that shows you less than half the information, and if you're motivated to check for more details, then you're welcome to scroll down?
  3. I never said that the book icon (with a ribbon bookmark) was not used at all. I said "On 2), the desktop site does not use those icons" to identify the Cite menu. The "Cite" menu is labeled with plain words on desktop (or "⧼MediaWiki:Visualeditor-toolbar-cite-label⧽" in your local language). You have supplied a link to the mobile web site. Mobile's design is necessarily constrained by the width of a smartphone, which could be less than 3 inches wide; as a result, when many options need to be provided, you really cannot spell out words. (Inside the desktop menu, there are multiple icons, but those icons are next to words that remove any possible confusion.) I know that you don't like the book icon, since you've said so repeatedly. User testing (with new editors) showed that the word "Cite" was much easier to understand than any type of icon. That's why the desktop design is using words. Whatamidoing (WMF) (talk) 01:07, 23 December 2014 (UTC)
Your definition of what constitutes a viable argument isn't much better than the WMF's concept of what constitutes a viable product. When VE is capable of editing all components of all existing articles on Wikipedia without introducing errors (or simply refusing to edit some bits), it's worth having a trial with novice users. Until it's functional, it's best left in the hands of people that know what they are doing. At this point, there is no consensus for making VE the default editor for any group of editors that hasn't explicitly done so themselves.—Kww(talk) 02:44, 30 December 2014 (UTC)
The WikiEditor can't even edit wikipedia without introducing errors, because you know, humans make typos. Oh right, but then we scold at people and those people go away, problem solved..... —TheDJ (talk • contribs) 10:12, 31 December 2014 (UTC)
It infuriates me when people parrot that ludicrous argument. You write code for a living, but make no distinction between bugs in your own code and compiler bugs?—Kww(talk) 23:25, 31 December 2014 (UTC)

A panel at San Diego Comic-Con?

You are invited to join the discussion at Wikipedia talk:WikiProject San Diego# Comic-Con Panel ideas discussion. Thanks. RightCowLeftCoast (talk) 07:06, 3 January 2015 (UTC)

Citation Activity History

I propose a small modification to the WP edit history code as follows:

(NOTE: I understand software a bit but I do not know how all the WP technical stuff works so if my terminology (I will use italics for my best guess on names of things) or if my assumptions on how things work technically (such as that WP uses a DBMS with tables and subtables) is erroneous please accept my apologies and please educate me. Thank you.)

1. Whenever a given edit is saved the WP software will do an automatic "change" comparison looking specifically for any changes involving any of the cite tags, and extract the text of those tags.

2. A copy of the entire citation would be used to create a new entry/record for a master citations database.

2A. If it is a web cite the entry would be indexed by URL + Title + access date.
2B. If it is an offline cite the entry would be indexed by Title + ISBN/ISSN/OCLC (if available) + page number (if available) + publication date.
(Other indexing schemes may be better than my suggestion and I welcome other suggestions.)

3. Using the above index, an entry would also be added to a new subtable of the edit history table which I would call the cite history table and cross-indexed to the diff id of the save being processed. The cite history table will also have a field I will call chtype.

3A. If the cite tag was not part of the pre-edit text the chtype = "added"
3B. If the cite tag is missing from the post-edit text the chtype = "removed"
3C. If the cite tag fields contents have been changed the chtype = "modified"

4. Finally the "View History" tab would be altered to display (with a user option to turn off/on) something like the following: 

 (cur | prev) 02:53, ◑ ◑ 1 January 2099 User3 (talk | contribs)‎ . . (126,118 bytes) (+375)‎ . . (→‎Discovery: new material) (undo)
              ☑ Cite Web "symbols" added: http://fsymbols.com/keyboard/windows/alt-codes/ "Keyboard symbols on Windows" (2014-12-30)
              ☒ Cite Book <no name> removed: "The Cat in the Hat" ISBN:978-0-394-90001-8 (1957)
              ✎ Cite Journal "moty2014" modified:  "TIME: 2014 Man of the Year" ISSN:0040-781X (2015-01-02)
 (cur | prev) 02:48, ◑ ◑ 1 January 2099 User2 (talk | contribs)‎ . . (125,743 bytes) (+220)‎ . . (→‎Chronology: new events) (undo)
 (cur | prev) 02:44, ◑ ◑ 1 January 2099 User1 (talk | contribs)‎ . . (125,523 bytes) (+636)‎ . . (→‎gramatical cleanup) (undo)

As to why, my logic is that this will help to visually see if an article is getting the citations it needs to improve, and it may also highlight when edit summaries do not match what was changed, or when citations are accidentally damaged by other edits.

Comments? 104.32.193.6 (talk) 22:07, 30 December 2014 (UTC)

  • Comment What makes citations special in this regard? When I have seen misleading edit summaries it is almost never citations. That aside, I know there has been talk about allowing bots to place tags, this does make me wonder if allowing a string comment with the tag make sense. PaleAqua (talk) 03:29, 31 December 2014 (UTC)
It's just a theory of mine but since citations are the vital red-blood cells of an article (without them the article dies) I thought it would be helpful if editors could see the adding and modifying of citations in an easy to view mode. Manually looking at long complex citation tags highlighted in diffs is prone to human information overload. Being able to see a quick add/mod/del and the key source id (url/title) would help reduce that overload and by placing this information in context with the timestamped edit history it shows the timing of such activity. When I see an article with a CN (or CN related) tag that somehow seems to have several citations I go looking to see if there have been any citations added/modified after the tag was inserted and if so when. I also look to see if the CN tag should have been removed after those citations were added, or if the CN tag needs to be updated to be more specific. On the other hand if I see lots of cites from non-RS then I am prone to add a CN tag or two. Having a quick list of what and when would be very helpful to me and I suspect others would find it so too. Looking to see if there is support. If not I suppose some sort of utility could be created to do an on-demand article history analysis. 104.32.193.6 (talk) 16:22, 31 December 2014 (UTC)
  • Comment A first step down this road could be to have a new edit tag added which indicates whether or not editing took place between <ref> </ref> tags. There is already a tag in place to signal when references are removed (see 'references removed' at Special:Tags) which I believe was instituted to help in anti-vandalism activities. I think it would be reasonably simple to revise the tagging code to generate a 'references added' tag, and somewhat more difficult to add code to generate a 'references revised' tag. Once those are in place, scripts could be written to extract the type of content inserted/modded/deleted. --User:Ceyockey (talk to me) 19:52, 31 December 2014 (UTC)
  • Warning if something like this is done there needs to be a small maximum number displayed in the edit history, with a link to View All if there are more. Some articles contain over 500 refs (example United States). A page move, or a massive reference reformatting, can generate an unlimited number of REF listings for a single edit in the edit history. A mere three revert-edits could then multiply that up to over two thousand entries in the edit history. And that's not even considering the mess if someone deliberately packed several thousand junk-refs into a single edit. Alsee (talk) 18:06, 3 January 2015 (UTC)
Comment on Warning: I appreciate the warning, it made me do some thinking. However I believe you may not understand what I am proposing...
  1. Remember that these entries would not be kept in the main edit history table but rather in a separate master citations database and a cite history (sub)table (see #2 & #3 in the original post above). The idea is to keep cite tag analysis completely separate from the actual article text.
  2. Maybe I do not understand but why would a WP page move alter the text within a citation tag? These tags are not "page location relative" since they almost exclusively reference off-wiki materials like books, movies, songs, or websites. Unless the actual tag text changes there should be nothing to trigger a listing.
  3. If the code to analyze for cite modifications is "key"==>"value" based, then a simple reformatting should not trigger a listing.
I do believe that this last criteria (key==>value analysis) does strongly push this proposal towards bot processing rather than FE processing. Question: Is there a way to have a bot crawl the edits across WP in the chronological order they were saved? Is that what the diff id represents? If so this would be the logical approach: to have a bot follow along and play catchup behind the editors.
This all being said, I do think User:Alsee's idea about a limit/view-all control is a very good idea! We could even make this "max number" user configurable (or at least let them toggle select the "view-all" default) for those who want to see more information on a regular basis. 104.32.193.6 (talk) 19:56, 4 January 2015 (UTC)

Proposed technical change: show pages expanded from redirects on Special:NewPages and Special:NewPagesFeed

The proposal is accepted. Drmies (talk) 17:56, 23 February 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.

Special:NewPages and Special:NewPagesFeed show all new pages, but they do not show pages that previously existed as a redirect but have been re-purposed into a content page. This is a significant loophole, allowing the creation of articles (many of which are necessarily content forks) that bypass the patrol pages entirely. I propose showing these pages on both aforementioned special pages, with a new filterable tag on NewPagesFeed, "Created from redirect". My questions:

  1. Does support exist for the proposed change?
  2. Is the proposed change technically feasible?

Any and all feedback is appreciated. (Edit: I've expanded the proposal to include Special:NewPages, in case anyone is still using it; I don't believe this significantly changes the proposal.) —Swpbtalk 14:28, 16 December 2014 (UTC)

(Second edit: filter 342 can already catch these pages; it's just a matter of re-enabling the filter and getting the pages displayed on the patrol pages.) —Swpbtalk 20:06, 18 December 2014 (UTC)

  • I suppose that could be another one for Wikipedia:Village pump (idea lab)/Archive 15#Bot tagging of edits if that idea gets off the ground. — {{U|Technical 13}} (e • t • c) 15:24, 16 December 2014 (UTC)
    I don't know about the technical limitations, but it seems these pages could be tagged by the edit filter, or whatever mechanism is currently used to identify new pages. I'm not opposed to bot tagging, I just don't want to tie this horse to that cart. —Swpbtalk 15:28, 16 December 2014 (UTC)
    The filter catching those edits was deactivated for being too expansive, the proposal for bot tagging of edits precisely aims to address those performance issues, since the bot would do the job instead of the edit filter. Cenarium (talk) 12:55, 19 December 2014 (UTC)
    Too expansive in what way? Was it catching false positives, or just causing too much server demand? I suppose it doesn't matter how the pages get tagged (filter or bot), as long as they can be added to the patrol lists. —Swpbtalk 17:06, 20 December 2014 (UTC)
    Too much server demand. Cenarium (talk) 13:09, 27 December 2014 (UTC)
  • Support if technically feasible. It probably is, since it does catch pages moved from user land to article land. Oiyarbepsy (talk) 15:38, 16 December 2014 (UTC)
  • Support We can easily tag these edits with an edit filter, and you could use the older Special:NewPages to detect them by supplying the tag name there. Updating Special:NewPagesFeed to show these tagged edits will require WMF involvement, I believe. — MusikAnimal talk 21:32, 16 December 2014 (UTC)
    Not sure how the tag alone would help. Special:NewPages still won't show the pages unless they're newly created. —Swpbtalk 01:00, 17 December 2014 (UTC)
    Ah of course, duh! I guess Special:RecentChanges is where you'd do your patrolling. Less than ideal. — MusikAnimal talk 17:22, 17 December 2014 (UTC)
    Not necessarily WMF involvement, but certainly developer intervention. Although most of the devs who understand NewPagesFeed are/were WMF people. — This, that and the other (talk) 04:56, 17 December 2014 (UTC)
    Indeed. I'm planning to enter a Phabricator ticket once it seems there's a consensus. —Swpbtalk 14:00, 17 December 2014 (UTC)
  • Support. Good idea if technically feasible or if not. The tags would be easy to use; just go through the edits that the tag catches. We just need to be careful to mark only the edits that cause the redirect to stop working (for whatever reason), because we don't want it to start flagging redirects that have just gotten marked with {{R from modification}} or a comparable template. Nyttend (talk) 02:34, 17 December 2014 (UTC)
    Indeed. I imagine the filter would look for the removal/breaking of the "#REDIRECT" syntax, rather than the addition of anything else. —Swpbtalk 14:06, 17 December 2014 (UTC)
  • Seems like a very sensible idea. It may be technically quite difficult to implement, though. Currently Special:NewPages is essentially a filtered version of Special:RecentChanges that only includes changes marked with the "N" flag. To check whether a page has gone from being a redirect to not being a redirect would require loading and inspecting the old revision of the page to see whether it was a redirect. This would have to be done for every entry in the recent changes table, which would be very taxing on the server. There could be ways around this but they would be quite complex to implement and would require very careful design on implementation on a huge wiki like this one. — This, that and the other (talk) 04:56, 17 December 2014 (UTC)
    Wouldn't it be fairly easy to implement a "created from redirect" edit filter/tag, and modify the special pages to include those pages, in addition to those with an "N" flag? —Swpbtalk 14:04, 17 December 2014 (UTC)
    Implementing the filter may be easy, I don't really know. (Yes, it's true that I am an "edit filter manager", but that doesn't really mean I know anything about the edit filter...) This could technically work by adding a flag to the edit filter system, allowing us to create filters that "add the page to Special:NewPages". But that in itself may be difficult to get working. — This, that and the other (talk) 11:08, 19 December 2014 (UTC)
  • Oppose. I am concerned this might result in increased erroneous attempts to delete (especially on the inapplicable grounds of notability) plausible redirects and mergeable content, which is already a problem. (The redirects will already have been patrolled once and identified as plausible). I think a list of such changes should at least be kept wholly seperate from NewPages. I am not convinced there is much need for this. No statistics have been offered as to the proportion of these pages which are invalid content forks. James500 (talk) 04:32, 18 December 2014 (UTC)
    To editor James500: Neither plausible redirects or mergeable content would be harmed under this change. The proposal is not for redirects to appear on NewPages; it's only for ex-redirects to appear. These are, for all practical purposes, totally new pages that have never been patrolled. And it's reasonable to assume that the proportion of such pages that are inappropriate will be at least as high as that among regular new pages, and probably higher; but at any rate, that's what patrol is there to sort out. Plausible redirects are in fact less likely to be deleted under this proposal, as they will no longer pose a risk of later becoming an un-patrolled article. And mergeable content created on an ex-redirect will actually be seen and merged (or at least tagged for merging), instead of languishing in un-patrolled obscurity as now. I hope you will re-examine your assumptions about how the proposed change works, and re-assess your position. —Swpbtalk 13:08, 18 December 2014 (UTC)
  • Ex-redirects are not practically equivalent to unpatrolled new articles. They are not new. They have already been patrolled once and found to be unsuitable for deletion. The difference between expanding a mainspace redirect and expanding an article seems small to me. It is not reasonable to assume that ex-redirects are as likely to be innappropriate as new articles. We redirect sub-topics, and a sub-topic of a notable topic is quite likely to be notable at our stage of development, which has incorporated only a small fraction of the information available from reliable sources. It isn't proposed to confine this to the expansion of redirects marked as redirects from an alternative name. In any event, we should proceed on real statistical evidence and not guesswork. I have seen far too many attempts to delete obvious redirects and mergeable content to assume that this proposed innovation will not result in mass nominations of them. I have even seen arguments at AfD along the lines of 'this should not be redirected/merged because it is non-notable' or 'we have an AfD on anything non-notable even if it is an obvious redirect'. If we do have an "expand redirect log", we will also need a "BLAR log" so that we can revert innappropriate blank and redirects. James500 (talk) 03:36, 19 December 2014 (UTC)
  • There are quite a few missing steps in the logic that leads from this proposal to "mass nominations" that lead me to believe you have no interest in actually understanding the proposal. —Swpbtalk 18:56, 20 December 2014 (UTC)
  • I understand the proposal perfectly. I also understand that lists of pages or edits can be used in a manner for which they were not intended.
  • Do you? Because the "list of pages or edits" being created here specifically does not include redirects; it's actually impossible for it to be abused to delete redirects, as you say. As for any other kind of "abuse", there's no reason to expect it. NPP is patrolled by inclusionists too, and they consistently force deletion-taggers to justify themselves. I myself frequently chastise editors who apply CSD tags outside their bounds. Any deletion taggings brought about by this change would surely face the same level of scrutiny. If that level of scrutiny isn't enough for you, then your argument isn't with the present proposal, but with the entire patrol system, or possibly with the current standards for inclusion. —Swpbtalk 13:35, 22 December 2014 (UTC)
  • Another issue is that, compared to new pages, these redirects are more likely to be on the watchlists of editors who regularly edit articles within the subject area of which the redirect is a sub-topic. There may therefore be no need for an ex-redirect article to be "patrolled" by editors who know nothing about the subject because it has already been examined by editors who are familiar with the subject. James500 (talk) 16:08, 21 December 2014 (UTC)
  • I reiterate that the pages we're talking about have not "already been examined" in any meaningful way, because of course the new content may bear no relation at all to the original target. Certainly, the quality of the original target article has nothing to say about the quality of the content on the newly un-redirected page. —Swpbtalk 13:35, 22 December 2014 (UTC)
  • That has nothing to do with what I said. It is possible watchlist a redirect. If a user has an article on his watchlist, he is likely to watchlist all the redirects to that article as well. If one of those redirects is subsequently expanded it will show up on the watchlist, and the user will presumably see it and examine the ex-redirect article. So, if you are worried that redirects to an article might be innapropriately expanded, all you have to do is find them with Special:WhatLinksHere and add them to your watchlist. Problem solved.
  • Another concern that I have is that, in addition to the lack of statistics and examples presented here, I cannot remember a single instance of a redirect actually being innapropriately expanded. James500 (talk) 08:37, 23 December 2014 (UTC)
  • I'm glad we don't have to rely on your memory. Your baseless "mass nominations" fear aside, you've still never presented a credible drawback to the proposal. —Swpbtalk 13:33, 23 December 2014 (UTC)
@Ironholds: I believe this is discussing old redirects being changed into articles (ie. de-redirected), as opposed to new redirects being created. --Mdann52talk to me! 17:37, 18 December 2014 (UTC)
  • Oppose These pages aren't new. This circumstance is more like a page move or regular content editing and so is best dealt with by the RecentChanges. Andrew D. (talk) 18:05, 20 December 2014 (UTC)
    • It's completely unlike a page move - in a page move, the content doesn't change at all. In this case, an entire new encyclopedia article can be created, and never once patrolled. —Swpbtalk 19:03, 20 December 2014 (UTC)
      • A page can be completely transformed at any time by ordinary editing, so creating an entirely new article. This sort of rewrite is not unusual and such changes are patrolled by looking at recent changes. We have this covered already and so don't need this creep. Andrew D. (talk) 01:47, 1 January 2015 (UTC)
  • Oppose including in new pages lists but support listing them in some sort of former redirect list. PaleAqua (talk) 18:34, 20 December 2014 (UTC)
    • You've stated your position, but you've provided no rationale for it. This is a discussion to uncover worthwhile considerations related to the proposal, not a vote on whether you like it. —Swpbtalk 18:59, 20 December 2014 (UTC)
      • The conversion of redirects into new pages seems like a different type of issue to watch for, ( specifically content forks ) and it seems to me that it would better to be able to watch from them seperately. The actions for content fork vs an unsuitable new page also seem like they would be different. Allowing different groups to watch different sets of page actions seems like a better use of wiki-editor power. PaleAqua (talk) 23:36, 20 December 2014 (UTC)
        • That's a reasonable concern, they are somewhat different issues — but I would argue that they're not so different as to demand a separate watchlist. For one thing, new pages are already frequently content forks, and regular NPP'ers understand what to do in such a case (merge any new sourced content, then redirect; or if there's no mergeable content, redirect or speedy the page, depending on the plausibility of the title as a search term). I think we should avoid splitting watchlists too finely, to avoid having underwatched lists. —Swpbtalk 13:42, 22 December 2014 (UTC)
  • Support if technically possible - these pages probably have nearly all the problems that new pages do. Even new pages may end up being redirected, and redirects which have been turned into articles are more likely to be restored to their redirect version than deleted. עוד מישהו Od Mishehu 07:33, 21 December 2014 (UTC)
  • Support This is another area where pages which really need checking can sneak in unnoticed. This seems like a sensible decision and I am unconvinced by the opposers' arguments. Sam Walton (talk) 02:09, 1 January 2015 (UTC)
  • Very strongly Support They sometimes will be perfectly straightforward, but this cannot be assumed, and therefore they need checking. In most cases where it is not simply a revert that may need discussion on the relevant talk page , it does amount to a new page creation that needs to be evaluated using the customary criteria. DGG ( talk ) 08:46, 4 January 2015 (UTC)
  • Support: Let me give a real-life example of why this is needed. See this page history. Originally it was a redirect from some NN company to its parent. The company was spun off, and an account apparently representative of that company added promotional, copyrighted text, replacing the redirect. This went unnoticed for 14 days until I spotted it while browsing an unrelated maintenance category, but such an action would not have been undetected had the page been put on NPP. BethNaught (talk) 19:20, 4 January 2015 (UTC)
  • ...or not. Special:NewPagesFeed (set to show all, oldest first) appears to be backlogged by more than 10,000 (ten thousand) articles, reaching back to September 2014. WhatamIdoing (talk) 23:13, 4 January 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.

Wiki Site for Politics

For a while now I have thought that that a wiki site for politics run in the same way Wikipedia is run would be a great idea. If successful, and formatted correctly, it could be a place where anyone would be able to go and see a concise and comprehensive set of each political party's stance on each issue, together with supporting evidence of this stance. For each representative, it could give a concise view of their stance, the reasons for the stance, and their history.

It would also be able to show where political party's have gone back on what they have previously promised, and provide supporting evidence. The party's themselves would be able to respond and defend themselves against the u-turns, and sound reasonable speculations/accusations for the u-turns could also be given be observers/other party's.

Politicians often appear to have ulterior motives for doing what they do, but some are very good at keeping this from the general public. The site would be able to allow reasonable accusations against suspect politicians to be more easily assessable, which would hopefully help weed out the more unscrupulous politicians.

If there was a place where people can see all aspects of the political debate in one place, this will allow them to make more informed decisions when voting, and could significantly enhance the political discourse in the average persons life.

If the site was successful and political parties and political commentators engaged, the site would auto-fill with all the necessary content. Also, if the site significantly improved the political process, the site could also justly gain funding from the Government.

I believe most people are resigned to the fact that the current political system requires politicians to be somewhat slippery and devious; if the site significantly increased the openness and accountability of politics, this could remove this necessity, and would therefore be welcomed by many well meaning politicians and aspiring politicians.

I think a big issue that a lot of people have with politics is that the don't trust the politicians, and that the arguments for an against issues can be unclear. A wiki site for politics run as successfully as Wikipedia could address these issues, and significantly strengthen the power of democracy.

I'd be interested to know if anyone else things that the idea has legs, and also the likelihood of something like this coming about. If anyone would be able to let me know if this has already been attempted, I'd also appreciate that. — Preceding unsigned comment added by Chrisb1985 (talk • contribs) 15:35, 4 January 2015 (UTC)

If such a site were not already in existence (or even if it was), then I'm sure you can get one started via Wikia. They host all kinds of different Wikis, devoted to pretty much any topic you can name. Kurtis (talk) 16:50, 4 January 2015 (UTC)
"The site would be able to allow reasonable accusations against suspect politicians to be more easily assessable" is a BLP nightmare, and there's no possibility the Wikimedia Foundation would touch something with such a high potential for libel with a barge-pole.Mogism
I do not know the first thing about the problems of BLPs, but I don't imagine maintaining the site would be any more difficult than any other wiki, if the people maintaining the site were to ensure that all posts were phrased correctly and linked to sources. I don't know wether highlighting facts and drawing reasonable conclusions can be considered libel? Chrisb1985
@Chrisb1985: The problem with BLP is not about "maintaining the site", it is about "staying out of court" for libel. Politicians typically (a) have money, (b) have legal experience (many are lawyers), and (c) depend upon their public reputations for their livelyhoods. A libel lawsuit tied to political activities could easily become a Constitutional rights lawsuit. A site such as the one you are suggesting would be wide open to such lawsuits and the only way to even stand a chance at safely running it would be to have a team of paid libel lawyers working as admins charged with approving each edit before it was made visible to the public. That is a nightmare! 104.32.193.6 (talk) 20:15, 4 January 2015 (UTC)
Yes, what 104.32.193.6 said. Open editing isn't usually a good idea for anything dealing with sensitive material involving living people, and articles would inevitably degenerate into supporters and opponents fighting to get their preferred version of every biography to be the visible one. Wikipedia doesn't handle this by way of "people maintaining the site", we handle it by the use of semiprotection to throttle the traffic on hot-button topics to a manageable level, by insisting on reliable sourcing for anything mentioned on-wiki, and by the liberal use of revision deletion to prevent unsourced allegations from remaining visible in the page histories. If I understand your proposal correctly, none of the three would be feasible under your model, as you want people to be able to raise speculation and gossip for discussion. Mogism (talk) 23:47, 4 January 2015 (UTC)
Actually, BLP is less about protecting ourselves from legal issues, and more about protecting people from being cast in an unduly negative light. It is an ethical consideration, one that takes into account the safety of the individual in question. Kurtis (talk) 04:06, 5 January 2015 (UTC)
Could the problem be side stepped then by only allowing people to post facts, backed up by sources, which are pertinent to the topic. (Redacted). I still think it is a great idea in theory, although no doubt that will be some issues that will need to be thoroughly thought through. Chrisb1985
And you reply to a comment about BLP concerns with... an unsourced libel against a Queen's Counsel in one of the most lawsuit-happy countries in the world. Redacted, needless to say. Mogism (talk) 20:44, 5 January 2015 (UTC)
No need to be smug. It was an absurd illustration, posted in an obscure part of the internet. Chrisb1985
That aside, I'm not sure you appreciate the scale of what you're suggesting. The United Kingdom general election, 2010 - a single election in a single relatively small and homogeneous country - was contested by 4,150 candidates from 134 parties, and even if you disregard the fringe parties that still leaves 10 major parties (as defined by the somewhat arbitrary criterion of having won at least one seat). Multiple that by 200+ countries in the world, many of which are politically far more divided, and you're looking at something that's a nightmare to maintain. Then of course, there's the question of expanding to coverage of local politics, where especially in somewhere like the US, there are literally hundreds of thousands of people standing for public office every year. Mogism
The hope would be that the parties themselves would fill in their own information, which would be critiqued by other parties and political commentators. Chrisb1985
If you're just talking about monitoring the activity of elected officials, I don't see how a wiki setup would offer any obvious advantage over the service already provided by They Work For You and its equivalents in other countries, and can see a lot of glaring drawbacks. Mogism (talk) 17:02, 4 January 2015 (UTC)
Thanks. I will have a look at the site Chrisb1985
Hmm, good point. It was actually only after I posted my earlier comment that I had thought about BLP; should have read his post more carefully beforehand. I'm not saying that there should be slander sites against politicians, just that creating a Wikia site dedicated to focusing on politics is a viable possibility. Kurtis (talk) 17:08, 4 January 2015 (UTC)
There's a site called Ballotpedia which seems to be exactly what we're discussing. -- Ypnypn (talk) 22:30, 5 January 2015 (UTC)
Thanks. Seems to do exactly what I was thinking of, but doesn't appear to be hugely successful. Hopefully it will expand to the UK at some point though. Chrisb1985

Bot tagging of edits

I propose that we allow bots to tag edits, and request the implementation of such a feature. The edit filter (and other extensions) can tag an edit before it is saved, but it isn't very effective at catching certain type of edits, and performance is a constant concern since each check makes saving an edit a tiny bit longer. On the other hand, a bot would tag an edit after it has been saved, which may take a few seconds due to processing and API lag, but removes any performance cost. There is already a request at phabricator, T3189, however this is for all users, not just bots, and it has stalled; a suggestion was made to have a community request to get it moving. Importantly though, I am proposing tagging for bots, and only for bots, for three reasons : more likely to gain strong consensus, much less likely to create issues that will have to be solved somehow, and no need for devs to create a user interface, since bots need only the API, meaning we'll get it implemented faster (of course this doesn't prevent devs from working on a UI for manual tagging, but whether we would enable this separate feature is for another discussion). The following are possible uses :

  1. edits identified as very likely to be vandalism, but not with a high enough likelihood for rollback or where rollback is prevented due to 1RR - for ClueBot NG (talk · contribs)
  2. edits containing urls that are potentially suspicious, but with enough legitimate uses that rollback is inappropriate - for XLinkBot (talk · contribs)
  3. student edits (looks like that extension doesn't have much support so we can't expect it to tag on its own any time soon)
  4. redirects transformed into articles - tagged by 342 (hist · log) but disabled for performance reasons
  5. probable cut and paste moves - for CorenSearchBot (talk · contribs) and incorporating 164 (hist · log)
  6. suspected copyright violations - for EranBot (talk · contribs) and CorenSearchBot (talk · contribs)
  7. cross namespace moves, this way we'll be able to filter them easily by tag in the move log 185 (hist · log) (disabled for performance), including the more specialized de-userfying 630 (hist · log)
  8. various template removals : speedy 29 (hist · log), images 59 (hist · log), copyvio 224 (hist · log)
  9. new articles : very short 98 (hist · log), large unwikified 180 (hist · log), 'autobiographies' 148 (hist · log), interrogative pages 289 (hist · log) (disabled for performance), pages created without categories 650 (hist · log)
  10. some other tag only edit filters such as inappropriate redirects 151 (hist · log) (disabled for performance) or undoing antivandalism bot 323 (hist · log)
  11. (Update 11:57, 5 January 2015 (UTC)) Deletion log entries by type : AFD, TFD, RFD, MFD, CFD, PROD, BLP PROD, CSD CRITERIA, selective deletion

We would also need a mass untag functionality available for admins in case of mistaken tags. Each bot tagging task would have to be approved. Cenarium (talk) 10:34, 13 December 2014 (UTC)

Definite support - tags are designed for automatic detection of suspicious edits, which can then be reviewed by human users to determine how bad they actually are. The ability for external automated programs to do this would be very helpful. עוד מישהו Od Mishehu 09:43, 21 December 2014 (UTC)
Huh? WP:Tags is all about brief messages that the software automatically places; they can't be placed by bots. Are you asking for a new software feature, enabling bots to tag edits after they're made? Are you asking for bots to be allowed to compile a list of edits that would otherwise be tagged? Unless you're saying that a bot should compile such a list (e.g. Special:Diff/123456789 expanded a redirect; Special:Diff/23456790 blanking, etc.), I don't see how your idea would work. If you want bots to go around compiling lists, I think you have a good idea. Nyttend (talk) 19:43, 21 December 2014 (UTC)
I'm asking for a new software feature, but we need to show there's support for it. Cenarium (talk) 13:50, 27 December 2014 (UTC)
Support in principle While I support in principle—especially for tags that would have too much impact on the server to be placed by an edit filter, but could still easily placed by a bot—there seems to be a few questions that need considering. For example is there a time window in which tags may be placed? How does this interact with recent changes? Should there be a recently tagged page? Will the tags added by bots be distinct from those added in other ways? If not what happens if a bot bug results in a large number of pages tagged that need to be revert where some of the pages already had and should keep the tag ? PaleAqua (talk) 20:23, 21 December 2014 (UTC)
To answer one question, we should make it mandatory that bots identify themselves in the tag itself, such as tag 12345, possible vandalism identified by Cluebot. Oiyarbepsy (talk) 22:04, 21 December 2014 (UTC)
Regarding your last question, it already happens with the edit filter that some of the edits are tagged but shouldn't have been. We make do with it, but in case of big fail, admins would just mass revert tagging. Bots should indeed identify themselves. Recent changes would show the tag after it has been placed by the bot. Cenarium (talk) 13:50, 27 December 2014 (UTC)
I would suggest starting with Cluebot NG - its borderline cases could tag edits as possible vandalism identified by Cluebot. It doesn't sound like any particular action is required to implement this now if we want, so a trial with a trusted bot may be the way to go. Oiyarbepsy (talk) 22:04, 21 December 2014 (UTC)
  • Support starting with Cluebot NG (talk · contribs) and gradually extending to other bots. Better than Edit Filter. Tony Tan98 · talk 05:41, 22 December 2014 (UTC) (10:11, 23 December 2014 (UTC): However, k6ka has a valid point below about perceived newbie biting if we start with ClueBot NG.)
  • While I am in support of this proposal, I do question us starting with ClueBot NG. For instance, ClueBot NG does list edits it knows is or suspects as possible vandalism but does not revert to reduce false positive rate - see User:ClueBot_NG#ClueBot-NG_RC_Feeds. You can see these edits with a tool like STiki. The idea is that it might cause a bit of newbie biting if CBNG makes a false positive here and tags their edit with "possible vandalism", rather than listing it on its IRC channel where a STiki user can make the final decision in private, without the editor knowing that the bot had done what it did. --I am k6ka Talk to me! See what I have done 13:50, 22 December 2014 (UTC)
    ClueBot NG is set for a maximum false positive rate of 0.1%, if we tag those edits matching for a maximum false positive rate of say 0.15%, and those which would have been prevented by the 1RR limit, the false positive rate would still remain very, very low. But you're right that the use of it may not be substantial enough on its own to override this concern, in fact this would be most useful as a supplement to deferring the edit, but that's for another discussion. Cenarium (talk) 13:50, 27 December 2014 (UTC)
@K6ka and Tony Tan 98: I think the biting concern can be addressed by having the option to set a tag as hidden, in a manner similar to hidden categories. Admins (or tag managers) could set a tag as hidden (reversible), which would have the effect to not display it, except if a specific user preference option is selected, and in that case it would be displayed separately in a hidden tags list. Cenarium (talk) 13:46, 5 January 2015 (UTC)
A bit of this is reassuring. The other thing is, if the bot is going to tag the edits itself, it needs to be capable of doing so, right? Should we ping Cobi (or maybe I already did that!)? --I am k6ka Talk to me! See what I have done 14:04, 5 January 2015 (UTC)
  • Support per above. MER-C 02:39, 23 December 2014 (UTC)
  • Support. If this is only used for purposes similar to the edit filter, maybe a configuration page similar to Special:EditFilter could list the approved uses and standardised tags. If suggestion 1 under "possible uses" is acceptable, this could also be made available as an alternative to rollback if any anti-vandalism tools use the API. Peter James (talk) 18:59, 24 December 2014 (UTC)
  • Support. I am in favor of developing new software capabilities of this sort, and I recognize that the details will be worked out over time. I've been strongly influenced by my experiences with the education program, and I think that eventually these capabilities will actually end up helping us to communicate better with student editors. That, in turn, will help us to improve the quality of the editing experience for students, and increase retention of student editors as regular editors. --Tryptofish (talk) 16:16, 27 December 2014 (UTC)
  • Comment This will rely on Phab:T20670. — {{U|Technical 13}} (e • t • c) 16:51, 27 December 2014 (UTC)
I had forgotten this one, it sounds like the good task because it doesn't ask for a UI to add tags. Cenarium (talk) 22:27, 27 December 2014 (UTC)
  • Support. As I said above in my "Huh?", it sounds like a good idea; my objections were all on "we can't do this now" grounds, which is irrelevant because Cenarium wants to request a new feature. Nyttend (talk) 19:47, 27 December 2014 (UTC)
  • Support, a good idea--Ymblanter (talk) 19:49, 27 December 2014 (UTC)
  • I've written a mass untagging feature, as requested by Cenarium in the original post, which is awaiting code review. The other parts of this shouldn't be too difficult to accomplish from a development perspective; it always comes down to finding appropriate people (MediaWiki experts) who have to time to review the code. — This, that and the other (talk) 11:26, 28 December 2014 (UTC)
    • Thanks @This, that and the other: for taking the initiative on the technical side. I've given some thought on the matter and written at User:Cenarium/Tags a suggested implementation for the enhancements needed. I suggest a hidden and a deleted flag for tags, and a cancelled flag for tag instances. Tag managers should also be able to define user-addable tags, provided they're not reserved by extensions. We'd likely need logs, a UI for tag management, and a UI for cancelling or un-cancelling tag instances (similar to special:nuke ?). It's close in spirit to what you've suggested at phabricator, and takes into consideration the feedback there and at github, as well as the need to hide tags. What do you think of those proposals ? I'll add a comment at phab later. Cenarium (talk) 16:35, 5 January 2015 (UTC)

Autotag Suffix Amendment

  • Support with an amendment. I hate seeing newbies chased off and since there is a danger (no matter how small) of newbie biting as pointed out by k6ka I have a concern. Instantly critical tags from bots could easily be seen as damned cold in the eyes of a newbie but would probably not be anywhere nearly so offensive if the newbie KNEW the tag was machine-generated and not some human picking on him/her. I propose the bot coder should add an "-autotag" suffix variety to each tag that his/her bot needs to use (and only to those tags so we don't have to be crazy). For example a bot that looks for weasle words would use {{weasel-inline-autotag}} instead of {{weasel-inline}} and the template text message could start by saying "The XYZbot software has detected the following possible issue:" followed by the normal tag text. Bots would not be allowed to use the "human" tags, only the "-autotag" suffixed ones. At the same time, humans could not use the autotag ones (they would be de-suffixed either by the EF or another bot). 104.32.193.6 (talk) 17:04, 31 December 2014 (UTC)

Brainstorming change tagging

As far as I'm concerned, phab:T20670 itself isn't in danger of being rejected. But besides the usual "find someone with time, talent, and motivation", are some outstanding questions as to how exactly things should work that should be answered before implementation:

  • Should there be a single user right covering both adding and removing tags, or should we separate these? Should mass-delete (TTO's patch) use the same right as deleting a single tag or a different one?
  • Should people with the right to add a tag be allowed to add any tag, or only existing/active tags, or only tags on a whitelist? Or should there be multiple rights, one for "add any tag" and one for "add only existing/active/whitelisted tags"? And should that "existing/active" be "existing" or "active"?
  • If we go with any sort of a "add only existing/active/whitelisted tags" plan, should deleting be similarly restricted?
  • Who should have these rights by default, sysops or autoconfirmed or all editors? Note that the defaults can always be adjusted for enwiki.

Brainstorming welcome. BJorsch (WMF) (talk) 13:30, 29 December 2014 (UTC)

  • Very good questions indeed. My thoughts on the matter are that any registered user should be able to add tags through the API or through JavaScript. I think the technical limitations to writing scripts and tools that use those methods would be generally enough of a barrier to keep abuse to a minimum. As far as deleting / merging / maintaining descriptions go, I think that sysop should be required for mass deletion of a tag, merging tags, and maintaining descriptions on Special:Tags and that each of those should be a separate userright in case there is a need to split parts of it off (say to allow TEs and/or edit filter managers to maintain the descriptions and merge - which I personally support, but don't expect that many others will for now) at a later date. Merging tags hasn't been mentioned before as far as I can tell, but it is a good idea when you have two tags for the same thing (ie "WikiLove" and "wikilove") they should be able to be merged into a single entity and all uses of the no-longer existent version updated to the new version. I think that single tag removals should be available to rollbackers as well as sysops, and again a separate userright. I also think that rollbackers should be given the ability to revdel (not see deleted content), but that is a completely different discussion for a different time. — {{U|Technical 13}} (e • t • c) 13:54, 29 December 2014 (UTC)
  • It's an interesting set of questions. Here's what I have in mind:
    • The managechangetags user right could cover tag management tasks - defining new tags, removing existing tags, renaming tags, merging tags... In the software this right would be assigned to sysops by default, but I'd imagine we would want to assign it to a separate group (a la edit filter manager).
    • An additional user right could be created to allow users to apply change tags as they edit (intended for use by bots and user scripts). I don't know to whom this would be assigned by default, but we could certainly assign it to the bot group at least.
    • A third user right could be created to allow patrollers to apply and remove change tags from existing revisions, if the feature is accepted. This would most likely be assigned to sysop by default, but we would almost certainly split it off into one of the finer-grained user groups, or possibly its own group.
    • I think that people should only be allowed to apply tags that are explicitly defined (i.e. have a corresponding row in the valid_tag table). It doesn't make sense for users to be able to tag edits as "VisualEditor" or "mobile edit". Special:Tags would have an interface for defining tags and managing which ones can be applied by users; only managechangetags users would see this tag setup inferface.
  • I haven't answered the third point, as I'm not entirely sure about it. — This, that and the other (talk) 01:48, 30 December 2014 (UTC)
  • In terms of userrights, we need one for adding a tag instance (addchangetags), it would be given to bots by default; there's only consensus for giving it to bots for now, we'll see in another discussion if we want to extend it, and other wikis may do as they please. Only one tag adding userright seems necessary for our needs. We need one for altering the status of individual tag instances (alterchangetags) : 'cancelling' or 'un-cancelling'. We then need a managechangetags userrright, given to admins by default, and also to edit filter managers on enwiki, to handle general tag management. They would mark tags as hidden, as deleted, and define user-addable tags.
  • Tags that can be added by users with addchangetags should be defined by tag managers, provided they are not reserved by extensions.
  • Having a 'deleted' flag similar to the abusefilter one would address the database and reversibility concerns, and this would work for tags with more than 5000 instances.
  • Having a 'hidden' flag would address BITING concerns, and may be used for some maintenance tags.
  • The ability to cancel individual tag instances (alterchangetags) is necessary to correct bot (or abusefilter) mistakes / false positives, and can be given to more people than tag managers.
  • The ability to rename and merge tags would be nice, but it's not necessary for release.
Cenarium (talk) 17:34, 5 January 2015 (UTC)
  • I've been thinking a bit more about having several tag adding userrights, and I think it would be useful to distinguish between bot and user added tags since we'll have user added tags eventually too and we need to ensure future compatibility. I've seen that TTO grouped tags by source in c182563, and I think we could go one step further and distinguish bot added tags and (non-bot) user added tags. We would then have two userrights addchangetags-bot, assigned to bots by default, and addchangetags-user, assigned to some usergroup as needed. Tag managers would define tags that can be added by bots, and tags that can be added by users. An observation on conflicts between tags added by different sources (OAuth app, AF, bot, user...). It's already possible to add tags like visual editor using the abuse filter. It would probably make sense to make it impossible to define AF tags added by OAuth, or bot addable and user addable tags added by OAuth, but it's not essential, I don't view this as a blocker for release. I've also suggested mediawiki core added invisible tags as a way to sort logs by action type. Cenarium (talk) 23:01, 5 January 2015 (UTC)

Question relating to timestamps: some of the watchlist functionality depends on the timing of a change relative to when the user last called up the watchlist. How would this work, if a tag is added (or removed) after the user has already seen the change before the tags were modified? --Mirokado (talk) 02:52, 30 December 2014 (UTC)

They wouldn't see the update. Cenarium (talk) 17:34, 5 January 2015 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_117&oldid=1090407471"