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

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.

---

Withdrawn - jc37 16:17, 23 June 2012 (UTC)

Proposal

• Special:ListGroupRights - (manual)

This has several parts.

1.) Ask the devs to create a separate user-right "edit-protected" so that one can edit admin-level protected pages, but that one cannot protect a page at admin-level.(edit-protected already exists as a user-right, but I understand there are some technical issues/concerns involved, which may require some rewriting of how protection works.)

This has the benefit of trusting people to edit protected templates (for example), but will calm the concern that those given the ability to protect (but not to block) will then protect pages in situations where individual blocking may have been more appropriate.

2.) Reassess the admin package (essentially splitting it):

a.) enhanced editing tools

b.) admin (sysop)

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 22:20, 20 June 2012 (UTC)

Discussion

In the discussion below, please bold specific user-rights is you mention them, in order to facilitate clarity in discussion : ) - jc37 22:20, 20 June 2012 (UTC)

The concept of an intermediate step between regular users and adminship seems like a good way of vetting potential admins. But then another process is required to give access to that level. What would be valid reason for requesting access to the pre-admin level: that you will have a use for the extra abilities or merely that you are trustworthy? IRWolfie- (talk) 22:49, 20 June 2012 (UTC)

Nod, though RfA could handle it as a separate section, similar to how it also handles RfB. - jc37 22:50, 20 June 2012 (UTC)

I note also that Elements of this proposal appear consistent and complementary to this other proposal: [1]. IRWolfie- (talk) 22:55, 20 June 2012 (UTC)

We've had a number of successful unbundlings - Rollback, Account Creator, File Mover, and innumerable unsuccessful attempts to create an admin lite user group who can partially do lots of admin things. If this proposal focuses on just unbundling Edit Protected then I think we have a viable and useful proposal. But please avoid complex Admin lite solutions. ϢereSpielChequers 23:17, 20 June 2012 (UTC)

I would also very much support unbundling Edit Protected. If this proposal was focused on just that, then I would support it. Silverseren^C 23:24, 20 June 2012 (UTC)

I've compiled a list on here.

But sure, I'm not opposed to editprotected being split as a separate userright - though note as it stands there are apparently some concerns dealing with cascading protection and the like. - jc37 23:30, 20 June 2012 (UTC)

My concern is: Where does the buck stop? We have had instances in the past of established editors edit-warring with each other on pages; if they both have this "edit-protected" right, then there is nothing to physically stop said edit war, as blocking has been established to be out of the question. --MuZemike 18:19, 21 June 2012 (UTC)

Any edits made without consensus on a protected page, especially after that edit has been questioned, should be grounds for immediate block. See Wikipedia:New admin school/Protecting#Full protection. Administrators should not edit a fully protected page without seeking consensus first, except when ignore all rules is applied well. On a separate note, is there a reason for this to exist separately from the village pump proposal? Ryan Vesey Review me! 18:36, 21 June 2012 (UTC)

If you mean Wikipedia:Village pump (proposals)#Proposal to ban instant blocking for established editors unless a warning has been validated issued first, I see what you mean. However, I'm sure different rules would need to apply in the situation I mentioned above that is different from that proposal. --MuZemike 18:48, 21 June 2012 (UTC)

I wasn't referring to that at all. I am stating that editors can't edit a protected page or template. Or at least shouldn't be. Giving rights to edit protected pages and templates isn't meant to create a list of users who are allowed to edit those pages. It is meant to create users who can evaluate the consensus and make the edit once it is reached. If that is not going to be the purpose of inclusion, I would oppose that userright in the bundle. Ryan Vesey Review me! 18:52, 21 June 2012 (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.