Wikipedia talk:Village pump (technical)/Proposal by Jc37/2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

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.

This proposal withdrawn by User:Jc37, see #Withdraw proposal below. Equazcion (talk) 08:09, 22 Jun 2012 (UTC)

Proposed new user-right group[edit]

Per Special:ListGroupRights

This group would essentially combine the following (already existing) groups:

  • Autopatrolled
    • Have one's own edits automatically marked as patrolled (autopatrol)
  • File movers
    • Move files (movefile)
  • Researchers
    • Search deleted pages (browsearchive)
    • Use higher limits in API queries (apihighlimits)
    • View deleted history entries, without their associated text (deletedhistory)
  • Reviewers
    • Edit semi-protected pages (autoconfirmed)
    • Have one's own revisions automatically marked as "accepted" (autoreview)
    • Hide feedback (aftv5-hide-feedback)
    • Mark others' edits as patrolled (patrol)
    • Mark revisions as being "accepted" (review)
    • Mark revisions as being "quality" (validate)
    • View hidden feedback (aftv5-see-hidden-feedback)

And would add three other userrights:

  • editprotected - allows to edit protected pages.
  • move-subpages - move subpages along with page.
  • suppressredirect - allows moving a page without automatically creating a redirect.

p This "enhanced editing tools" user-right group would essentially be filled with user-rights which also happen to be in the admin package, which may be useful for trusted editors.

Essentially over time, we've found that quite often that a few of our most prolific editors are also unfortunately not individuals who we feel we could trust with the discernment required for use of tools such as block/protect/delete. But yet we would have no problem trusting them editing protected pages, moving pages, uploading files, and so on.

So this would have several benefits. First (and most importantly) it put the tools in the hands of those who would benefit from them. (A template coder who could edit high usage/visibility protected templates for example.) Second, it provides a sort of "preadminship" tier of trust, which may help to better see how the individual handles the greater responsibilities, if the individual decides later to request adminship or any other individual tools.

The enhanced editing tools package wouldn't include any user-right already given out by admins (such as rollback), nor would it give out any user-rights which would allow the individual to block another editor or in any way affect that editor's ability to edit. So for example marking their own edits as reviewed, but not another editor's. The idea is that this is all about editing the encyclopedia. Those tools which police other users' and/or their edits should not be part of this package.

Several years ago, we were told by the devs that they were not wanting to add another "tier" between editor and admin. However in the years since then, we've had an explosion of user-rights and user-right packages. So I think we could re-examine the situation.

Please feel free to discuss below. - jc37 01:29, 21 June 2012 (UTC)[reply]

Discussion[edit]

Which tools should be in the enhanced editing package based upon the criteria I set out above? (I can accept that there are those who will want the package to include tools like rollback or block, but they can discuss that in a separate section : ) - jc37 22:30, 20 June 2012 (UTC)[reply]

I am strongly in support of creating suppressredirect as its own user right, or bundling it with rollbacker. There are many times where editors need to userfy pages or fix vandalism moves and need to suppress a redirect to do so. I believe anyone entrusted with rollbacker should also be entrusted with suppressredirect. Ryan Vesey Review me! 00:27, 21 June 2012 (UTC)[reply]
Nod.
As for rollbacker, I'm intentionally leaving rollbacker out of this proposal. The most that this user package does in regards to other editors' edits is "mark them somehow". Rollbacker should stay it's own userright. - jc37 00:48, 21 June 2012 (UTC)[reply]
I am unsure of my thoughts on creating an entire new package that would include some sort of half-RfA, but I strongly think that suppressredirect should be either combined with rollbacker or given to users in the same way as rollbacker. In fact, I was going to create that exact proposal but hadn't gotten around to it yet. Ryan Vesey Review me! 01:00, 21 June 2012 (UTC)[reply]
Wait, your proposal isn't to include editprotected, move-subpages, and suppressredirect. It is to combine the 4 listed and create the other 3 as new userrights? Ryan Vesey Review me! 01:06, 21 June 2012 (UTC)[reply]
Sorry. As I was working on the RfA reform proposal, I realised it was developing into something different.
To clarify: To merge the 4 groups AND the 3 other user-rights into a single package.
That said, I welcome suggestions concerning what others feel should and should not be added to this package.
The idea is that this user-right should be about enhanced editing tools, and at most would be about assessing edits, and not editor behaviour. - jc37 01:18, 21 June 2012 (UTC)[reply]
  • Two questions: This looks like you want to deprecate autoconfirmed, but I'm assuming that wasn't the intended meaning? Also, does anything here mean "view deleted pages"? Equazcion (talk) 01:16, 21 Jun 2012 (UTC)
    No that wasn't the intention, the confirmed user-right group has it's own set of user-rights, though you're right a couple are duplicative with some of the above groups.
    And no. what would be able to be viewed AFAIK, would be the list of deleted contribution (but not the contributions themselves). - jc37 01:22, 21 June 2012 (UTC)[reply]
  • The researcher userright allows editors do view the history of deleted pages. It is designed for people doing doing research. I don't know what the purpose of putting that userright into the bundle would be. Specifically since people who have it are specifically approved by the Wikimedia foundation. Ryan Vesey Review me! 01:20, 21 June 2012 (UTC)[reply]
    Admins have these user-rights. And they can be useful for editors. Please remember that I'm not proposing how this package should be handed out, merely the creation of it here. That's for a separate RfC : ) - jc37 01:24, 21 June 2012 (UTC)[reply]
    Okay, more questions though. What would happen to people who already have some of these? Would they get the package automatically or have to be re-confirmed to receive the package? And, why not include a new right (or make it part of the package) to view deleted pages? This would be useful for non-admins who want to help people who've had their articles deleted. I've had many occasions where that would've been great. Also, what's the rationale for combining things instead of keeping them separate? You might want to explain your reasons somewhere, as at least to me, it's not really apparent. Equazcion (talk) 01:30, 21 Jun 2012 (UTC)
    Ok, to be honest, because I've been in these sort of discussions many times over the past several years, and would like to have something that will (hopefully) pass : )
    Allowing non-admins to view deleted content is a non-starter for some people for various reasons - privacy, copy-vio etc. What I've done here is let these trusted editors see what edits may exist, and then an admin is merely a talk page request away : )
    And I've expanded things somewhat - this sort of grew out of a different proposal.
    And please, ask away. I'm happy to clarify. I have no doubt that I have info in my head that I'm not realising others (such as yourself) would want explained/clarified : ) - jc37 01:39, 21 June 2012 (UTC)[reply]

I would support creating a bundled move-subpages and editprotected. Continuing to allow Autopatrolled, file movers, and reviewers as separate userrights. Finally, I think suppressredirect should be its own userright or bundled with rollbacker. I believe move-subpages and editprotected should take a slightly more in depth process to receive. Ryan Vesey Review me! 01:26, 21 June 2012 (UTC)[reply]

Actually, I would support the entire enhanced userrights group, including researchers, as long as autopatrolled, file movers, reviewers, and suppressredirect are also available as single userrights. Ryan Vesey Review me! 01:32, 21 June 2012 (UTC)[reply]
I'm not incredibly opposed to this, but why? - jc37 01:44, 21 June 2012 (UTC)[reply]
I would oppose any bundling of current rights. Difficulties become created in that editors like me, who only have reviewer rights or one of the other rights, need to be dealt with. Do you remove the right, or give all of them? There are autopatrolled editors who I wouldn't want to give the editprotected right. In addition, I find the move-subpages and editprotected rights to be the ones that require the most trust, which is why I would want them in a bundle. The other rights are ones that I think users may want individually. I wouldn't mind having a suppressredirect right, I happen to userfy pages decently often. Ryan Vesey Review me! 01:49, 21 June 2012 (UTC)[reply]
Well, autopatrolled and reviewer, I can easily see as remaining separate as well as combined in the new package. The rest really are ones that require more trust (as you note), and in some ways would benefit being in a package rather than separate. The move-related abilities, for example, with edit protected would be useful for many different applications. And when editing a protected page, it could be important to see who may have made edits in the past (now deleted) before helping with an editprotected request. - jc37 02:06, 21 June 2012 (UTC)[reply]
You have a good point. I would support the proposal exactly as it exists in your last response. Autopatrolled and reviewer continue to exist, we create a bundle for them and everything else. Ryan Vesey Review me! 02:40, 21 June 2012 (UTC)[reply]
Sounds good to me. Now I just have to figure out how to phrase it into proposal-speak lol - jc37 02:46, 21 June 2012 (UTC)[reply]
  • Note I added this to Template:CENT. Jc37 may want to edit the text in case I didn't explain the intent correctly, as this is still sort of fuzzy to me. Equazcion (talk) 01:37, 21 Jun 2012 (UTC)
  • Oppose - Now that I have a better understanding of this proposal (I think), I'm not really in favor of it. I'm all for the continued unraveling of the admin rights into separate assignable groups, and would like to see more of those; in particular, editprotected would be useful for me as a template guy (for the reason Jc37 mentioned), and ability to view deleted pages would be great for helping the myriad of new editors who complain about their deleted articles. But I think they should all remain as separate rights. It's good that these rights are no big deal to assign individually, if an editor is seen as trustworthy and knowledgeable in a particular area, or conversely, revoked individually if they've shown a lack of those qualities in a particular area. For a package of rights like these, I might even see a process developing to assign it, and/or one to revoke it, and I think we need less of that sort of thing, not more. I think this would be a step in the wrong direction, so long as we otherwise do keep adding individual assignable rights. Equazcion (talk) 01:56, 21 Jun 2012 (UTC)
    One of the goals here would be to lighten up the heaviness at RfA, not cause more.
    And in the past, I've seen some admins give out user-rights like candy. So I'm not sure what your concern is. please clarify? - jc37 01:59, 21 June 2012 (UTC)[reply]
    As I see it, the most basic problem with RFA is that adminship constitutes an eclectic set of rights that everyone is nervous about assigning as a whole to any individual. Candidates need to somehow show they can handle all of them, whether or not they actually need/have proven their ability to use all of them, or they get none. This package would have a similar problem, although to a lesser extent. In that regard, I think keeping the rights individualized and nicely focused, and continuing to make new ones available, is a better solution to the RFA problem. If admins are not being careful about user rights assignment, that should probably be addressed through education, though since the rights are no big deal to revoke when abused, it's not that much of a problem. Equazcion (talk) 02:09, 21 Jun 2012 (UTC)
    mark edits; advanced move; view edit lists; edit protected. Not only are all of these directly related to editing, but (unlike adminship and the big arguments over delete and block and over block and protect) these are presumably items with congruent trust levels.
    With that in mind, what is your direct concern? or in other words, how do you imagine what you suggest will come to pass? - jc37 02:17, 21 June 2012 (UTC)[reply]
    I don't think rights should be thought of in terms of "levels". I know how to tell if a page would get speedied, but I know next to nothing about file naming; hence I have autopatroller but not filemover rights. I think there's more logic to that system than asking what level of trust a user has attained; I'd even say that that thought process is part of the evil of RFA. As to how it would play out, perhaps proving oneself with enough of the individual rights would make RFA smoother; someone who can already do most of the things admins can do would be able to clearly show whether they've been doing them right, reducing the need for fuzzy character judgment. And/or, perhaps eventually the need for bona fide admins will be much more rare, with most of the admin rights being available individually. Equazcion (talk) 02:31, 21 Jun 2012 (UTC)
    I said trust levels not rights levels. I was referring to various "trust levels" that have been argued ad infinitum concerning adminship. But anyway, I was responding to your comments above. I understand that you'd like all rights separate. But I don't know if that's something which would ever get consensus. - jc37 02:43, 21 June 2012 (UTC)[reply]
    I understand (I think), but nevertheless, I'm saying that if rights are individually focused, we wouldn't need to determine a trust level to serve as bar-to-entry for a given set of rights, so much as determining a proven level of skill and judgment with a particular aspect. Again, going back to filemovers vs. autopatrollers, I don't think we should be setting a trust level where someone gets both. What if someone's only shown an aptitude for one? Do they get neither, or do we decide we must trust them with both? That's one of the problems with RFA. As for consensus for individual rights, I think we're already doing this gradually. I'm (obviously?) not suggesting an attempt to obtain consensus for a one-shot proposal to offer all admin rights as individual assignable ones. Equazcion (talk) 02:55, 21 Jun 2012 (UTC)
    I agree, though only to a point. Some user-rights work just fine separately, but some are better interdependantly. And by the way, if you look over the current set of user-rights, there is a fair amount of redundancy built it. (Though to be fair, I honestly don't know if that was intentional or merely as a result of past things still hanging around in the system.) - jc37 04:00, 21 June 2012 (UTC)[reply]
  • You might want to let someone from the WMF know about this proposal. Last I heard, they weren't allowing anything to do with viewing deleted revisions be unbundled. Jenks24 (talk) 03:34, 21 June 2012 (UTC)[reply]
    Please feel free. Though note that this proposal does not add the ability to see the content of deleted edits, merely the edits (the difference between seeing a page and the edit history of a page). - jc37 03:54, 21 June 2012 (UTC)[reply]
    I think Jenks has a point. I doubt WMF wants reviewer privileges given out, so specific permission would need to be granted before an RfC of any sort. Ryan Vesey Review me! 03:58, 21 June 2012 (UTC)[reply]
    If that was true, the researcher group wouldn't already exist. Please don't confuse seeing an edit history with seeing a page's content. - jc37 04:09, 21 June 2012 (UTC)[reply]
  • Strong Support - I actually loved the idea of creating those additional groups. I strongly support this idea because giving out this rights to trusted users will largely benefit the community. Number of active admins has been going down, so if few additional rights are available to trusted users, they can help a lot and not wait for any admin to do that. →TSU tp* 03:38, 21 June 2012 (UTC)[reply]
  • Question: Would this "enhanced editing tools" user-right group have the ability to edit the Main Page directly? Even admins who edit the Main page are shown this edit notice warning them that any modification that resembles vandalism might be perceived as one made by a compromised account (because of its high visibility, the Main Page has historically been one of the first targets of vandalism by a compromised account). And there have been cases where admin accounts have been immediately temporarily blocked and their rights suspended for such suspicious edits. This may be another issue where some may be hesitant on giving more editing access too. Zzyzx11 (talk) 04:00, 21 June 2012 (UTC)[reply]
    The main page is cascade protected I think? Which means that we are straying into an area which may require those with more knowledge than I. (I'll have to re-read the various explanations. But basically my understanding is that editprotected can't directly edit cascading protection.) - jc37 04:06, 21 June 2012 (UTC)[reply]
  • Support - The phrasing is a bit condescending — "not trusted enough for blocking buttons, etc." rather than the more common "many editors who can use certain buttons who think RfA is a dysfunctional circus and will submit themselves to that garbage when pigs fly." Still, the idea is sound. There are certain things that would be useful to serious WP people who have no desire to run the RfA gauntlet. In my case, being able to see a deleted page now and again when making a start of a deleted topic or at AfD would be useful. The basic idea is that there are too many tools in the Administrator "package" and there probably should be some sort of "Lite" version for wide distribution that's, ummmm, no big deal... Carrite (talk) 04:38, 21 June 2012 (UTC)[reply]
"...note that this proposal does not add the ability to see the content of deleted edits..." — Meh, that's the only thing on the list of the slightest interest to me, personally. Carrite (talk) 04:41, 21 June 2012 (UTC)[reply]
There are two problems with allowing non-admins to view deleted material. First, there is a lack of desire by WMF. The major concern is because copyrighted material is deleted. The second is technical Wikipedia:New admin school/Viewing deleted pages makes it appear like to give someone the ability to view a delete page you would need to give them the ability to restore the page. Ryan Vesey Review me! 12:15, 21 June 2012 (UTC)[reply]
I see this as only a minor convenience and not worth the risk. It is easy enough to ask an admin to cut and paste the deleted material to your personal sandbox if it isn't copyrighted, Outing, etc. --Guy Macon (talk) 02:07, 22 June 2012 (UTC)[reply]
  • This avoids the two most contentious areas of adminship - deleting pages and blocking editors. As such it might just possibly get consensus, but it risks falling foul of the usual objections to admin lite, and if it got through there is also a risk of this achieving a similar increase in RFA standards as unbundling Rollback did. I don't see the point of including Autopatrolled in with anything else - I'd happily see it removed from the Admin bundle. Autopatrolled is easier to get now than it used to be as we've lowered the threshold to 50 articles and that has broadened it more than the tightened BLP rules have narrowed it. As for suppress redirect, I'm seeing this misused by a number of admins so I'm loathe to broaden it. In my book moving a newbie created page without either leaving a redirect or informing the newbie is very bitey , so I'm uncomfortable giving that to someone who I wouldn't necessarily support for adminship. I'd support unbundling Edit Protected, but if you unbundle a package of userrights you really need to design that for a particular group of editors who can't or won't get the Mop but are trusted in other ways. So Vandalfighters who can block vandals but not delete pages is a sensible unbundling for people who don't need the content rights but can be trusted to block vandals. ϢereSpielChequers 08:08, 21 June 2012 (UTC)[reply]
  • Support this or smaller unbundlings of these specific tools. Part of the reason I support this proposal is that it doesn't look like admin-lite. If there's no blocking/protecting/deleting then nothing this new usergroup can do would be seen as having serious community-impacting effects. I mean, shit, we let non-admins have abuse filter rights, and that can cause far more harm than all of the above userrights combined. So again, I support this as long as it's not interpreted as "admin-lite" or "a step to adminship". It's a bundle of tools that may be useful to some editors. We should let trusted editors modify templates that had to be permalocked due to vandalism. Seeing pieces of deleted pages is useful for anyone trying to help a newbie who asks why his page was deleted. And the rest are all things that editors normally have to ask an admin to do, but a smart user would know when such a thing is not controversial. So, yeah. For a third time, I totally support this as a sensible unbundling of rights that admins have no need to have a monopoly on. Someguy1221 (talk) 08:46, 21 June 2012 (UTC)[reply]
  • Support - This sounds good. There are a lot of content contributor that has no interest in mop related activities that don't want to or wouldn't be able to pass RFA that would benefit from this, and who would benefit the project with such access. KTC (talk) 11:44, 21 June 2012 (UTC)[reply]
  • Support - This is excellent. These tools naturally bundle well together, and users who are trusted with one can reasonably be trusted with all of them. This will also take a lot of workload off of admins. Plus, it avoids the problems with the perennial limited admin proposals by not giving these people even a limited block or delete ability, tools that should be restricted heavily. I would say that the majority of regular contributors, people who have rollback, etc, could be trusted with these tools, tools that many probably want and need but don't want to subject themselves to an RfA for. The one question I have is how viewing deleted content would handle copyvios. Other than that (perhaps remove that tool from the bundle), I would strongly support this. Specs112 t c 15:08, 21 June 2012 (UTC)[reply]
  • Comment - I would reject any attempt to give me the power to block users because I believe having this power would compromise my effectiveness in mediating disputes. On the other hand, if the ability to edit protected pages was available, I would request it at once. I have seen pages that went under full protection because of vandalism while containing typos and dead links. I believe that I have established myself as not being a vandal, and it is silly that I cannot fix obvious problems because someone else is a vandal. --Guy Macon (talk) 15:49, 21 June 2012 (UTC)[reply]
  • Pages should rarely be full protected for vandalism. In any case, consensus needs to be formed to edit a full protected page even if this userright was given. Obviously there is a bit of WP:IAR for spelling mistakes and unsourced negative biographical information. Ryan Vesey Review me! 18:47, 21 June 2012 (UTC)[reply]
  • Support and include suppressredirect as well as abusefilter-view-private because the first can cause no damage (a revert is in fact made easier) and the second is required for completely reviewing stuff at WP:Edit filter/False positives/Reports (since many edit filter entries can't be viewed by non-admins).--Jasper Deng (talk) 17:09, 21 June 2012 (UTC)[reply]
  • Oppose. Suppressredirect is actual page deletion, viewdeleted is a copyright problem, and editprotected is a major issue; allowing someone to edit the Main Page or frequently used templates without the vetting of RFA is a very bad idea. The other bits I have no problems with trusted users having — like rollback, they're admin tools that simply make normal editing easier, rather than outright enabling something that's otherwise impossible. Nyttend (talk) 18:40, 21 June 2012 (UTC)[reply]
  • I would like to remark that suppressredirect doesn't delete a page. When you move an article, the media-wiki software has you create a redirect. Suppressing the redirect keeps that from being created. Viewedeleted is not an option. Editprotected is an issue, and it might be possible to discuss a form of this without editprotected, otherwise I think it will come down to whether or not the editors can be entrusted to edit protected pages. Editing a protected page is contingent on being able to recognize consensus once it is established, if an editor can do that, I don't see a lot of reason that they shouldn't have the rest of the tools in this bundle. Ryan Vesey Review me! 18:47, 21 June 2012 (UTC)[reply]
  • Strong Support Being trusted to follow editing policies and being trusted to deal with behavior problems are two completely different things, and should be unbundled. I would even suggest allowing the possibility of an admin who is trusted to deal with problem editors without being trusted to know all everything needed to be a trusted editor. --Guy Macon (talk) 18:44, 21 June 2012 (UTC)[reply]
  • Support, or at least moral support, because I think we need to find more alternatives to RfA. I agree with WereSpielChequers' analysis. I also am not sure how this package of tools would be given out. If I understand correctly, there would not be an RfA for this. Would any administrator be able to name someone to this, as with rollbacker? Would there be a "quality control" process involved in that? I ask, because too many people got reviewer under that last pending changes trial; it was given out indiscriminately, kind of like candy. And would there be any kind of procedure for revoking the rights if they are badly used? --Tryptofish (talk) 20:18, 21 June 2012 (UTC)[reply]
    • It should be a normal request for user rights. Obviously the user should not have a history of edit warring (including move warring) nor any CSD'd pages.--Jasper Deng (talk) 20:46, 21 June 2012 (UTC)[reply]
      • Due to including edit protected and several other such userrights, I think this will need to be bureaucrat granted. But as far as what "process" for them being granted is a subject for the next RfC. At this point, the purpose of this discussion is just to get consensus for the user-right package so that we can show the devs that this is wanted and has consensus. - jc37 22:42, 21 June 2012 (UTC)[reply]
  • oppose, as a volunteer. Autopatrolled and reviewer are completely different things, and for good reason - one says "I have written decent content", the other says "I have identified it". They are not the same thing. Ironholds (talk) 22:45, 21 June 2012 (UTC)[reply]
  • Support — I'm not entirely sure if I'd want to be an administrator (or that I'd pass at RfA, given how obscure incidents of anything can damn it outright), but the access levels being proposed as part of this user rights group would almost certainly be beneficial to me as a non-admin. I think I can be trusted not to misuse these privileges. Master&Expert (Talk) 22:47, 21 June 2012 (UTC)[reply]

Comment on Edit-protected[edit]

Having seen views here and on other spots on the encyclopedia, I think there is a large misconception as to what giving the edit-protected userright would entail. If this cannot be cleared, I would not support including the userright in this package. Having the ability to edit protected pages does not give a user the ability to make changes to pages as they wish, just because we trust them. Having the ability allows a user to make a change that has been backed by consensus. I'm not entirely sure I would like that to be given to editors who have not actually gone through a vetting process by the community. It creates too great of a chance of misuse and I believe an RfA-like process could adequately determine whether an editor is able to determine consensus and make edits to protected pages in that manner. Perhaps this could be a good trial for one of the alternative RfA processes currently being discussed. Ryan Vesey Review me! 20:58, 21 June 2012 (UTC)[reply]

  • If they know what edit warring protection is, they shouldn't have any problems. Edit warring through full protection is abuse of this privilege, just like abuse of any other userright. This is why no user who gets this should have a history of edit warring.--Jasper Deng (talk) 21:05, 21 June 2012 (UTC)[reply]
    • But this is much more than edit warring. If a page is under full protection, and I feel information should be added to the article, I need to seek consensus on the talk page. That applies even if I had the edit-protected userright. It doesn't seem like all of the editors here and editors commenting elsewhere understand that. You must remember that a majority of the time that full-protection is placed on an article, it is due to an ongoing content dispute. Edit warring shouldn't be abuse of the privilege, it should be an unimaginable event because editors with the userright should know not to add information without seeking consensus first. That being said, an editor should be able to revert another addition if consensus wasn't sought first with no problems. Ryan Vesey Review me! 21:14, 21 June 2012 (UTC)[reply]
      • Protection because of a content dispute=protection against edit warring, though what I really should have said instead of "edit warring" is deliberately adding something against talk page discussion. Since an admin added protection in the first place, I'm pretty sure that admin can take away this userright instantly for such a violation.--Jasper Deng (talk) 21:27, 21 June 2012 (UTC)[reply]
        • Right, I am saying that my concern goes beyond edit warring. I fear that editors with a misunderstanding of this userright will use it to edit fully protected pages and templates without seeking consensus first. Like I've mentioned before, there is a clear ignore all rules aspect where they could, but in a majority of situations they shouldn't. Ryan Vesey Review me! 21:30, 21 June 2012 (UTC)[reply]
          • Respecting consensus is extremely important. It's something anyone with this permission must have. Since any admin should be able to judge this ability it should be clear who gets it and not.--Jasper Deng (talk) 21:38, 21 June 2012 (UTC)[reply]
            • If I am given this user right I have every intention to use it without seeking consensus on the talk page. I plan on correcting obvious typos without asking anyone for permission. I plan on fixing dead links when a reference moves a page to a new URL without seeking consensus. That's because in such cases I do not believe that there is any requirement to seek consensus before editing fully protected pages. And I am pretty sure I am right about this. As for the actual content dispute that resulted in full protection, I wouldn't touch that with a ten foot pole. --Guy Macon (talk) 01:42, 22 June 2012 (UTC)[reply]
              • Well, minor edits like that probably don't hurt. I believe Ryan's concern is only about content dispute protection, anyways.--Jasper Deng (talk) 01:47, 22 June 2012 (UTC)[reply]
                • Alas, the protection bit makes no such distinctions. It stops me from fixing typos and from violating consensus. I think it would be reasonable to require someone to read a help page and to indicate that they have read and understood it and have no questions before giving them the trusted editor user right --Guy Macon (talk) 02:01, 22 June 2012 (UTC)[reply]
                  • You are given a notice when you are granted rollback, from the admin who granted it to you. This user right should work very similarly.--Jasper Deng (talk) 02:06, 22 June 2012 (UTC)[reply]
              • Guy Macon, that is completely reasonable use and covered by WP:IAR. Consensus isn't needed for typo corrections and fixing dead links. Consensus is needed for changes to content. Ryan Vesey Review me! 02:39, 22 June 2012 (UTC)[reply]

WMF view[edit]

Hey guys

So, I've been reading this page and had a talk with some of the staff. I may be misunderstanding, but - are we talking about a userright that could just be handed out by any admin?

If this is the case, I'm sorry, but we're not going to make the technical changes :(. The particular problem is the ability to view deleted revisions and pages that's part of the "researcher" usergroup; in previous discussios, General Counsel has made clear that allowing non-administrative users to have access to these tools is not acceptable. Okeyes (WMF) (talk) 22:51, 21 June 2012 (UTC)[reply]

Fine, that userright can be excluded. Then is it acceptable?--Jasper Deng (talk) 22:52, 21 June 2012 (UTC)[reply]
Then I'll have to talk to people in more detail :). It wasn't a dedicated and nuanced round-table with engineering and legal, more a "uh, guys from legal, didn't you say this wasn't okay? Okay, want me to tell them that?" thing. I'll check in with legal and engineering (and may give this conversation to Maggie - my remit is more limited in this area than hers). Okeyes (WMF) (talk) 22:54, 21 June 2012 (UTC)[reply]
Jc37 has clarified that this wouldn't include the ability to view the content of deleted revisions. It would only allow viewing of their history listings (as I understand it). Equazcion (talk) 22:59, 21 Jun 2012 (UTC)
I can't be sure. Unless a techie says so I can't rely on it.--Jasper Deng (talk) 23:01, 21 June 2012 (UTC)[reply]
Ah, then this may be a different ballgame :). I'll poke a dev. Okeyes (WMF) (talk) 23:06, 21 June 2012 (UTC)[reply]
(edit conflict)Remember that sometimes auto-edit summaries can contain the bad content of deleted pages too. If you're having to hide the content, you may end up having to hide summaries too. If legal don't want the content of deleted revisions visible, then I don't think allowing edit summaries (and hence history) is a good idea, but let's see what they have to say about it. [stwalkerster|talk] 23:11, 21 June 2012 (UTC)[reply]
Hi folks, I'm sorry, but I don't think we can approve allowing the history of deleted pages to be viewed by anyone but administrators. It's just unacceptable legal risk. I'm not aware of any mission critical use cases for that, but if you think you can convince me of one, give it a go.  :) (I suggest email as the fastest way to reach me - philippe@wikimedia.org ). Philippe Beaudette, Wikimedia Foundation (talk) - for the WMF legal team. 00:04, 22 June 2012 (UTC)[reply]
We get the reasons, but I'm not sure why the hardline stance. Wouldn't it depend on the eventual process and prerequisites implemented for granting this? Admins are just people that have been put through a process. Maybe, Philippe, you could outline some criteria (editor prerequisites/process) that could make you feel comfortable with this? Equazcion (talk) 00:42, 22 Jun 2012 (UTC)
I think the WMF legal team is right. Take my own case. I can demonstrate that I can be trusted to edit protected pages. I can not demonstrate that I can be trusted to view the history of deleted pages (I actually can be trusted; I just can't prove it.) That's because anyone can see the entire history of my edits. The history of what I have viewed on Wikipedia and what I have done off-wiki with that information can not and should not be seen by anyone. So in the one case you can trust me and I can prove it. In the other case you would be fools to trust me. --Guy Macon (talk) 01:53, 22 June 2012 (UTC)[reply]
That argument would work if we didn't let anyone see that stuff, but admins can, and they don't provide the kind of proof you describe. We just have a process we put them through and a set of prerequisites that make us (and the legal team, apparently) comfortable enough to say they can, should they pass. With the reduced privileges of this package, I would think there is some lesser process and criteria that would make them similarly comfortable with it. Equazcion (talk) 02:10, 22 Jun 2012 (UTC)
I've mentioned before that WMF doesn't want the reviewer right given out. Why argue it? Personally, I see no reason to view the deleted history of the page. Can anyone provide me with a good argument of what they would do being able to see the history of a deleted page without viewing the content for anything other than research purposes? Ryan Vesey Review me! 02:41, 22 June 2012 (UTC)[reply]

Withdraw proposal[edit]

Hi. I'm having internet issues (which is annoying).

Due to this, I haven't been here to try to clarify in the midst of some seeming confusions concerning some of this. (including some WMF comments which I would indeed wish to respond to.)

Also, I've now read the page as it currently stands, and can see that there are things that need thinking over, and I also think now that this proposal needs to be modified. Rather than try to do that in the middle of the discussion, I respectfully request someone please close this as "withdrawn".

As soon as my connection is more trustworthy, I'll post a revised proposal. Right now, I don't trust my connection enough to do much more than post this. - jc37 08:02, 22 June 2012 (UTC)[reply]

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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Village_pump_(technical)/Proposal_by_Jc37/2&oldid=1142662419"