Wikidata:Requests for comment/Restructuring of the "minor" user rights
An editor has requested the community to provide input on "Restructuring of the "minor" user rights" via the Requests for comment (RFC) process. This is the discussion page regarding the issue.
If you have an opinion regarding this issue, feel free to comment below. Thank you! |
THIS RFC IS CLOSED. Please do NOT vote nor add comments.
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
- This is a reclosure;
- Proposal 1: Passes with 75%.
- Proposal 2: This is a tough one. Statistically, 66% are in favour. However, a lack of compelling reasoning, in fact any reasoning from users which is flawless is leading me to close it purely based on arguments. Therefore I am going to be slightly controversial and pass this. If this becomes an issue in the future, it can be reconsidered assuming hard evidence is provided as opposed to 'I think this will happen.' As far as I can see, this will have no damaging effects on Wikidata short or long term except the fact it will reduce this small workload from administrators.
- Proposal 3: Pass with 75% and Prop 1 & 2 passing.
- Proposal 4: Fails.
- Proposal 5: Suppressredirect for rollbackers.
- Proposals 6 to 11: All fail.
John F. Lewis (talk) 19:48, 8 November 2013 (UTC)[reply]
I hereby give users the chance to propose some changes regarding our local user groups.
Contents
- 1 Current situation
- 2 Proposal 1: patrol permission for autoconfirmed + confirmed groups
- 3 Proposal 2: autopatrol permission for autoconfirmed + confirmed groups
- 4 Proposal 3: abolish autopatrolled group
- 5 Proposal 4: merge rollback group to autopatrolled group or autopromote for rollback group
- 5.1 Support merge
- 5.2 Oppose merge; support autopromotion to rollbacker after 100 edits and a clean block log for accounts older than 14 days
- 5.3 Oppose merge; support autopromotion to rollbacker after 250 edits and a clean block log for accounts older than 14 days
- 5.4 Oppose merge; support autopromotion to rollbacker after 500 edits and a clean block log for accounts older than 14 days
- 5.5 Oppose merge; oppose autopromotion
- 6 Proposal 5: supressredirect for rollbackers and property creators
- 7 Proposal 6: abusefilter-view-private for rollbackers
- 8 Proposal 7: new abusefilter manager user group
- 9 Proposal 8: add noratelimit and markbotedits rights to rollbacker
- 10 Proposal 9: unwatchedpages for rollbackers and property creators
- 11 Proposal 10: abusefilter-log-private for rollbackers
- 12 Proposal 11: make a user right to override Spamblacklist
Current situation edit
- (auto)confirmed: Some minor rights like moving pages and editing semi-protected pages
- autopatrolled: autopatrol + patrol + (auto)confirmed rights
- rollback: rollback + autopatrol + patrol + (auto)confirmed rights
- propertycreator: property-create + autopatrol + patrol + (auto)confirmed rights
Proposal 1: patrol permission for autoconfirmed + confirmed groups edit
I propose to give autoconfirmed users the patrol
permission (Mark others' edits as patrolled). This is already done this way on the English language Wikipedia, and I see no reason why it shouldn't be this way here either. Our requirements for autoconfirmed are also even higher (50 edits vs. 0). Since the rights of the confirmed group are the same as those of the autoconfirmed group, they will also be changed. Vogone talk 01:27, 14 October 2013 (UTC)[reply]
Support proposal 1 edit
- Vogone talk 01:27, 14 October 2013 (UTC)[reply]
- by ReviDiscussSUL Info at 06:05, 14 October 2013 (UTC)[reply]
- --Glaisher [talk] 16:53, 14 October 2013 (UTC)[reply]
- patrol rights are not big deal I think. --DangSunM (talk) 17:01, 14 October 2013 (UTC)[reply]
- --Steinsplitter (talk) 17:33, 20 October 2013 (UTC)[reply]
- Sounds good. Groups are duplicating each other as they definitely have the same purpose… --Base (talk) 16:24, 22 October 2013 (UTC)[reply]
- I Support the proposal. Patrol is really no big thing and especially on wikidata there is no real need to patrol edits as there are really much better ways to find vandalism. Patrol adds a huge amount of unpatrolled edits to the log and nobody can really check all of them. If we reduce the size of this log to users who are really new it will also be much more useful as it is atm. Best regards, Bene* talk 21:12, 22 October 2013 (UTC)[reply]
- Support.. Shanmugamp7 (talk) 17:27, 26 October 2013 (UTC)[reply]
- --GZWDer (talk) 07:44, 30 October 2013 (UTC)[reply]
- I support this, and I will apreciate if they do this indeed. I think that in the future we will need to patrol changes because there will too much them, so everyone will be able to help. Matěj Suchánek (talk) 15:35, 30 October 2013 (UTC)[reply]
- Support Makes sense. Ajraddatz (Talk) 19:45, 1 November 2013 (UTC)[reply]
- Support From my observation, almost all edits that need to be patrolled come from users that are not autoconfirmed. The Anonymouse (talk) 07:33, 7 November 2013 (UTC)[reply]
- Let's do it -- Ата (talk) 19:21, 8 November 2013 (UTC)[reply]
Oppose proposal 1 edit
- "This is already done this way on the English language Wikipedia" - not exactly, the English Wikipedia is set up differently than Wikidata, with only new pages needing patrolling. I've also seen too many accounts at that site trying to game autoconfirmed. --Rschen7754 01:35, 14 October 2013 (UTC)[reply]
- How is this related to the proposal? We in fact also use the patrolled stuff for new pages only and I don't see why the wiki config here should make any difference regarding how much we trust autoconfirmed users (besides, autoconfirmed is even harder to get than on enwiki). Vogone talk 01:40, 14 October 2013 (UTC)[reply]
- "We in fact also use the patrolled stuff for new pages only" - no, we use it for all edits from nonautopatrolled editors. --Rschen7754 01:42, 14 October 2013 (UTC)[reply]
- The wiki config is like that, yes. But nobody uses it in practice "for all edits from nonautopatrolled editors" and it was already discussed at several places to change the wiki config to new pages only. Vogone talk 01:45, 14 October 2013 (UTC)[reply]
- And again, how is this even related to the proposal? Vogone talk 01:47, 14 October 2013 (UTC)[reply]
- "We in fact also use the patrolled stuff for new pages only" - no, we use it for all edits from nonautopatrolled editors. --Rschen7754 01:42, 14 October 2013 (UTC)[reply]
- How is this related to the proposal? We in fact also use the patrolled stuff for new pages only and I don't see why the wiki config here should make any difference regarding how much we trust autoconfirmed users (besides, autoconfirmed is even harder to get than on enwiki). Vogone talk 01:40, 14 October 2013 (UTC)[reply]
- Oppose per Rschen7754.--Jasper Deng (talk) 06:34, 14 October 2013 (UTC)[reply]
- Funnily Rschen7754 gave no arguments in this case. He just complained about 2 of my formulations … Vogone talk 06:36, 14 October 2013 (UTC)[reply]
- Any automatic system can be gamed, per Rschen7754.--Jasper Deng (talk) 06:45, 14 October 2013 (UTC)[reply]
- What is the confirmed user group for an automated system and how can the patrolled user right be gamed? Vogone talk 06:47, 14 October 2013 (UTC)[reply]
- All you do is make 50 userspace edits, and then you have autoconfirmed. Adding patrolled would be even more problematic. --Rschen7754 07:09, 14 October 2013 (UTC)[reply]
- Not even the worst spambot would make 50 edits and wait 4 days hoping not to get blocked just for abusing the patrolled right, not even speaking of the autopatrolled right. Vogone talk 07:20, 14 October 2013 (UTC)[reply]
- It's vandals that we are concerned about. They can slip below our spotlight if their edits get marked as patrolled automatically.--Jasper Deng (talk) 07:21, 14 October 2013 (UTC)[reply]
- Also vandals wouldn't make 50 halfway constructive edits and wait 4 days just to abuse the (auto)patrolled right … Vogone talk 07:23, 14 October 2013 (UTC)[reply]
- Yes they would. I've dealt with plenty of vandals who go to such extremes.--Jasper Deng (talk) 07:52, 14 October 2013 (UTC)[reply]
- And you honestly think that it would be easier than just writing some stories on WD:RFOR and requesting the right directly there? Furthermore, why would a vandal need patrol? I don't think vandals do intend to help us with patrolling some pages, neither do they have any good chance not to appear in our RC feeds. (Furthermore I can't believe you to know such vandals as they surely don't observe InitialiseSettings.php and stuff.) Vogone talk 10:32, 14 October 2013 (UTC)[reply]
- We can refuse requests at RFOR, as they are clearly and publicly visible. Vandals can hide themselves with patrol. You will have to take my word for it, I dealt with many such LTAs on enwiki long before I became a cross-wiki Wikimedian.--Jasper Deng (talk) 22:09, 14 October 2013 (UTC)[reply]
- If you can show me 1 vandal who did this successfully here on Wikidata I might change my opinion on this matter. As the 50 edits/4 days ap for autoconfirmed is already in place for some months now these vandals already had and still have enough chances to game autoconfirmed here. If this really was the case, then we should also consider to create separate user groups for other "abusable" rights like
move
,editsemiprotected
or evenautoconfirmed
(and force a non-automatic summary so that "undo" can't be used like rollback, anymore). Vogone talk 23:32, 17 October 2013 (UTC)[reply]
- If you can show me 1 vandal who did this successfully here on Wikidata I might change my opinion on this matter. As the 50 edits/4 days ap for autoconfirmed is already in place for some months now these vandals already had and still have enough chances to game autoconfirmed here. If this really was the case, then we should also consider to create separate user groups for other "abusable" rights like
- We can refuse requests at RFOR, as they are clearly and publicly visible. Vandals can hide themselves with patrol. You will have to take my word for it, I dealt with many such LTAs on enwiki long before I became a cross-wiki Wikimedian.--Jasper Deng (talk) 22:09, 14 October 2013 (UTC)[reply]
- And you honestly think that it would be easier than just writing some stories on WD:RFOR and requesting the right directly there? Furthermore, why would a vandal need patrol? I don't think vandals do intend to help us with patrolling some pages, neither do they have any good chance not to appear in our RC feeds. (Furthermore I can't believe you to know such vandals as they surely don't observe InitialiseSettings.php and stuff.) Vogone talk 10:32, 14 October 2013 (UTC)[reply]
- Yes they would. I've dealt with plenty of vandals who go to such extremes.--Jasper Deng (talk) 07:52, 14 October 2013 (UTC)[reply]
- Also vandals wouldn't make 50 halfway constructive edits and wait 4 days just to abuse the (auto)patrolled right … Vogone talk 07:23, 14 October 2013 (UTC)[reply]
- It's vandals that we are concerned about. They can slip below our spotlight if their edits get marked as patrolled automatically.--Jasper Deng (talk) 07:21, 14 October 2013 (UTC)[reply]
- Not even the worst spambot would make 50 edits and wait 4 days hoping not to get blocked just for abusing the patrolled right, not even speaking of the autopatrolled right. Vogone talk 07:20, 14 October 2013 (UTC)[reply]
- All you do is make 50 userspace edits, and then you have autoconfirmed. Adding patrolled would be even more problematic. --Rschen7754 07:09, 14 October 2013 (UTC)[reply]
- What is the confirmed user group for an automated system and how can the patrolled user right be gamed? Vogone talk 06:47, 14 October 2013 (UTC)[reply]
- Any automatic system can be gamed, per Rschen7754.--Jasper Deng (talk) 06:45, 14 October 2013 (UTC)[reply]
- Funnily Rschen7754 gave no arguments in this case. He just complained about 2 of my formulations … Vogone talk 06:36, 14 October 2013 (UTC)[reply]
- Let me break this down.
- This is already done this way on the English language Wikipedia
- It's largely irrelevant what is done where. Why is it important to us here that English-language Wikipedia does it this way?
- and I see no reason why it shouldn't be this way here either.
- I do not see sufficient cause to change from the status quo. Please provide more detailed reasoning.
- Our requirements for autoconfirmed are also even higher (50 edits vs. 0).
- Because edits are more trivially performed here, and for no other reason. In fact, given their triviality, this point hurts your argument (which you so far have none).
- Since the rights of the confirmed group are the same as those of the autoconfirmed group, they will also be changed.
- Cool?
So, in all, I see no argument put forth for why this should be done. My oppose is procedural, minimally.
I also share JD's and RS's concerns, so that's actually a very firm oppose from me. --Izno (talk) 22:37, 14 October 2013 (UTC)[reply]
- Well, the description you just analysed was obviously just an introduction to this section and no argumentation at all as I prefer to discuss different opinions in a "request for comment" rather than just providing a one-sided argumentation over each section. The supporting resp. opposing arguments should come from the commenting community members in the respective sections and I hope you understand that.
The reasons for proposing this seemed quite obvious to me. Firstly, we would reduce the admin's workload by 1 rather needless task. Secondly, autopromotion is a very effective way to prevent any kind of hat collecting as wikis like the German language Wikipedia or the English language Wikibooks who already assign their minor flags via autopromotion already have shown. For example, drama-causing situations like the WorldTraveller101 case would be very unlikely to happen again. I consider these tiny advantages to be stronger than any risk which would be caused by the rather unlikely case that autoconfirmed is "gamed" by vandals. Kind regards, Vogone talk 23:32, 17 October 2013 (UTC)[reply]- But we're lucky if we get 1 rights request a day. --Rschen7754 06:02, 19 October 2013 (UTC)[reply]
- Some more breakdown.
- Firstly, we would reduce the admin's workload by 1
- Lol? It's not like administrators have excessively difficult work on a timeline, like closing AfDs on en.wp. We delete things, mostly CSD candidates; we block and rollback obvious vandals; and we close the occasional difficult discussion, such as at PfD or at RFC. The workload of administrators is not high.
- rather needless task
- Whether the task is "needless" is what is under dispute in this RFC, no? Injecting the word doesn't make your case better.
- Secondly, autopromotion is a very effective way to prevent any kind of hat collecting as wikis like the German language Wikipedia or the English language Wikibooks who already assign their minor flags via autopromotion already have shown.
We do not have anything more than occasional problems with hat-collecting, and I think a large number of participants on Wikidata are sensitive to hat-collectors. Which, by the way, hat-collecting to me is getting a right and then not using it, for which we a) already have protections; and b) doesn't do any harm to the wiki any way for those which don't have protections. If hat-collecting to you means "getting a right and then abusing it", then see case (a) of the previous statement. Most rights are trivially removed, which is a positive reason I would rather have finely-grained rights than have the kinds of monolithic rights that would make up autoconfirmed in your world or which make up sysop in both of our worlds.
- drama-causing situations like the WorldTraveller101 case would be very unlikely to happen again
- I would rather have drama-causing situations for every single questionable case. Every single one. Because it leaves the power with the wiki-users who are already trusted and established, rather than those who, in exactly such a case, are questionable. And while that sounds like I support a cabal, that is not the case.
- In other words, you're still unpersuasive. :) --Izno (talk) 16:01, 19 October 2013 (UTC)[reply]
- A thing you should know is that this was never intended to be a big change. So please also don't expect it to be big. What I am trying to do here is simply "to show that [I] have tried to gain consensus, and that [I] have given an opportunity for objections" which is required for changes, regardless how big or small they are. If you try to make it a big change, you won't succeed as it simply isn't. Thus you also can't expect strong and super-convincing arguments for either side. Furthermore, I will also not be able to convince a user who strongly opposes "monolithic rights" and autopromotion, in the same way like you wouldn't be able to convince me of the opposite. I just have the experience to have worked on wikis with both systems and always felt that on these wikis which don't have x+n user groups but just a few which are based on autopromotion had a far better climate regarding user rights, hat collectors and similar things as these "problems" have only little chance to occur there. It is your right to oppose all these things, and there is really nothing I can do about that. So I guess further "break-downs" of my comments would be rather pointless :) Vogone talk 20:09, 19 October 2013 (UTC)[reply]
- Okay, one more time! :D
- never intended to be a big change
- Irrelevant. A change is a change. I am not evaluating this as a big or small change, but simply as a change.
- Thus you also can't expect strong and super-convincing arguments for either side
- Untrue. You have not yet debated against my points, so either they are salient or you don't care to, neither of which shines positively on your attempt to change.
- also not be able to convince a user who strongly opposes "monolithic rights" and autopromotion, in the same way like you wouldn't be able to convince me of the opposite
- Irrelevant (and an ad hominem argument). Argue against the argument, not the person.
- always felt that on these wikis which don't have x+n user groups but just a few which are based on autopromotion had a far better climate regarding user rights
- I am deeply skeptical of this claim, given that you first claimed 'en.wp does it this way'. My experience, working solely on en.wp, has been that x+n user groups would have prevented much of the pain that has been caused at RFA there and elsewhere. People who need the tools can get the tools they need, and those who don't, won't.
- In summary, you still have not argued persuasively. --Izno (talk) 15:25, 27 October 2013 (UTC)[reply]
- A question: What are your points?
As far as I see in your initial comment your oppose was "procedural" and you "share JD's and RS's concerns". I already debated against both of the points.
Regarding the "ad hominem" argument, I've already explained my thoughts in the sentence you analysed one line below and the sentences you analysed in your second last "break down". Since you feel "deeply s[c]eptical" about my claim, there is really not much more I can do to convince you of the opposite except to give you the advice to work on a wiki where things go that way.
Regarding the "you first claimed 'en.wp does it this way'" sentence; I only claimed that enwiki does it that way with the patroller user right, nothing else. Proposal 2, 3 and 4 also belong to the things I have proposed and of course it makes even less sense to conduct proposal 1 only as this would change nothing about the situation and the number of user groups would stay the same. Vogone talk 15:59, 27 October 2013 (UTC)[reply]- "Skeptical" is American English. ;) The Anonymouse (talk) 07:33, 7 November 2013 (UTC)[reply]
- A question: What are your points?
- Okay, one more time! :D
- A thing you should know is that this was never intended to be a big change. So please also don't expect it to be big. What I am trying to do here is simply "to show that [I] have tried to gain consensus, and that [I] have given an opportunity for objections" which is required for changes, regardless how big or small they are. If you try to make it a big change, you won't succeed as it simply isn't. Thus you also can't expect strong and super-convincing arguments for either side. Furthermore, I will also not be able to convince a user who strongly opposes "monolithic rights" and autopromotion, in the same way like you wouldn't be able to convince me of the opposite. I just have the experience to have worked on wikis with both systems and always felt that on these wikis which don't have x+n user groups but just a few which are based on autopromotion had a far better climate regarding user rights, hat collectors and similar things as these "problems" have only little chance to occur there. It is your right to oppose all these things, and there is really nothing I can do about that. So I guess further "break-downs" of my comments would be rather pointless :) Vogone talk 20:09, 19 October 2013 (UTC)[reply]
- Well, the description you just analysed was obviously just an introduction to this section and no argumentation at all as I prefer to discuss different opinions in a "request for comment" rather than just providing a one-sided argumentation over each section. The supporting resp. opposing arguments should come from the commenting community members in the respective sections and I hope you understand that.
- Per Rschen7754. --AmaryllisGardener (talk) 16:32, 26 October 2013 (UTC)[reply]
Proposal 2: autopatrol permission for autoconfirmed + confirmed groups edit
I also propose to give autoconfirmed users the autopatrol
permission (Have one's own edits automatically marked as patrolled). Since marking edits as patrolled is basically only done to say the edits were not vandalism, this will do no harm, as one can see after 50 edits whether someone is a vandal or not. Vogone talk 01:27, 14 October 2013 (UTC)[reply]
Support proposal 2 edit
- Vogone talk 01:27, 14 October 2013 (UTC)[reply]
- by ReviDiscussSUL Info at 05:10, 14 October 2013 (UTC)[reply]
- Glaisher [talk] 16:54, 14 October 2013 (UTC)[reply]
- --DangSunM (talk) 17:01, 14 October 2013 (UTC)[reply]
- --Steinsplitter (talk) 17:33, 20 October 2013 (UTC)[reply]
- Support -- Bene* talk 21:12, 22 October 2013 (UTC)[reply]
- per section above, i haven't noticed that it is just about one right. --Base (talk) 15:16, 23 October 2013 (UTC)[reply]
- Support Autopatrol to Autoconfirmed is not a big deal IMO.--Shanmugamp7 (talk) 17:28, 26 October 2013 (UTC)[reply]
- Support Ajraddatz (Talk) 01:53, 28 October 2013 (UTC)[reply]
- --GZWDer (talk) 07:46, 30 October 2013 (UTC)[reply]
- Support If proposal 1 is implemented, this one should be implemented also. The Anonymouse (talk) 07:34, 7 November 2013 (UTC)[reply]
- -- Ата (talk) 19:21, 8 November 2013 (UTC)[reply]
Oppose proposal 2 edit
- Per votes above. --Rschen7754 01:37, 14 October 2013 (UTC)[reply]
- Oppose--Jasper Deng (talk) 06:34, 14 October 2013 (UTC)[reply]
- Definitely not. Users can trivially request this right, and there are even admins (myself included) who will provide this right without request. --Izno (talk) 22:30, 14 October 2013 (UTC)[reply]
- So if you give it to everyone anyway, why not assign it automatically? --MF-W 12:20, 15 October 2013 (UTC)[reply]
- Did he say to everyone? I also give it manually for many users, but only if I know/see that they are trusted enough. --Stryn (talk) 13:37, 15 October 2013 (UTC)[reply]
- I think Stryn hits that nail on the head. I do not "give it to everyone anyway". I assess their edits, whether their user page is filled in, whether they may be an editor moving a page from the UI on Wikipedia and are trusted there, and so forth... It is a trivial right, but that does not mean that I assign it with triviality. --Izno (talk) 22:00, 15 October 2013 (UTC)[reply]
- Naturally "everyone" needs to be read as "account with 50 edits + over the autopromotion age" in the context of this proposal. Do you know users who have more than 50 edits, are not blocked, but which nevertheless don't fulfill your criteria for giving them autopatrol? --MF-W 12:48, 16 October 2013 (UTC)[reply]
- In my past experience, such users might have edits that either look questionable or can't be checked due to language barriers. --Jasper Deng (talk) 17:15, 16 October 2013 (UTC)[reply]
- Naturally "everyone" needs to be read as "account with 50 edits + over the autopromotion age" in the context of this proposal. Do you know users who have more than 50 edits, are not blocked, but which nevertheless don't fulfill your criteria for giving them autopatrol? --MF-W 12:48, 16 October 2013 (UTC)[reply]
- So if you give it to everyone anyway, why not assign it automatically? --MF-W 12:20, 15 October 2013 (UTC)[reply]
- Per above. --AmaryllisGardener (talk) 16:33, 26 October 2013 (UTC)[reply]
- Legoktm (talk) 23:45, 26 October 2013 (UTC)[reply]
- Weak oppose StevenJ81 (talk) [Changed to Weak oppose at 14:23, 29 October 2013 (UTC)][reply]
- Is there any reason why you opposed especially this? Vogone talk 20:31, 28 October 2013 (UTC)[reply]
- For starters, I think the fact that someone has put an eyeball on people's activity is good public policy. Beyond that: those of you who are extremely active may not always appreciate the fact that these "minor" rights are very encouraging to those of us starting out. We feel some appreciation and trust from this, and it encourages us to get more involved. Don't sell that idea short.
- I'm agnostic about proposal 1. And I don't know enough about some of the rights mentioned far down the list to have an opinion. StevenJ81 (talk) 01:08, 29 October 2013 (UTC)[reply]
- I don't quite understand. How do you feel more appreciation for getting a user right without doing anything but asking on WD:RFOR than for getting a user right for having done anything (50 edits)? Vogone talk 14:09, 29 October 2013 (UTC)[reply]
- I didn't ask. Someone offered it to me. And I appreciated that. That's all. I presume, per your point above, that someone had seen me do something in order to offer me that flag. So I didn't see it as "getting something for nothing".
- You're making a bigger deal out of my oppose than I intended it to make. I'll refile it as weak oppose. I do not feel extremely strongly, but on the whole I would prefer things to remain as they are. StevenJ81 (talk) 14:23, 29 October 2013 (UTC)[reply]
- Ah, okay. If you meant this, "[t]he manual granting of [(auto)]patrolling rights can obviously still be handled by sysops by giving users the confirmed status". :) Cheers, Vogone talk 14:28, 29 October 2013 (UTC)[reply]
- I don't quite understand. How do you feel more appreciation for getting a user right without doing anything but asking on WD:RFOR than for getting a user right for having done anything (50 edits)? Vogone talk 14:09, 29 October 2013 (UTC)[reply]
- Is there any reason why you opposed especially this? Vogone talk 20:31, 28 October 2013 (UTC)[reply]
Proposal 3: abolish autopatrolled group edit
If proposals 1 and 2 are adopted, the rights of the (auto)confirmed groups would be equal to those of the autopatrolled group, making the latter useless. It would therefore make sense to abolish it. The manual granting of patrolling rights can obviously still be handled by sysops by giving users the confirmed status. Vogone talk 01:27, 14 October 2013 (UTC)[reply]
Support proposal 3 edit
- Vogone talk 01:27, 14 October 2013 (UTC)[reply]
- Per my vote above. --by ReviDiscussSUL Info at 06:07, 14 October 2013 (UTC)[reply]
- Makes sense if 1 & 2 are successful. --Glaisher [talk] 16:56, 14 October 2013 (UTC)[reply]
- --DangSunM (talk) 17:01, 14 October 2013 (UTC)[reply]
- If 2 is adopted. Ajraddatz (Talk) 01:46, 15 October 2013 (UTC)[reply]
- --Steinsplitter (talk) 17:33, 20 October 2013 (UTC)[reply]
- Support -- Bene* talk 21:12, 22 October 2013 (UTC)[reply]
- per sections above. --Base (talk) 15:18, 23 October 2013 (UTC)[reply]
- Support--Shanmugamp7 (talk) 17:29, 26 October 2013 (UTC)[reply]
- --AmaryllisGardener (talk) 15:07, 29 October 2013 (UTC)[reply]
- --GZWDer (talk) 07:44, 30 October 2013 (UTC)[reply]
- Support Autopatroller would then be redundant. The Anonymouse (talk) 07:35, 7 November 2013 (UTC)[reply]
- All three first proposals should be approved. There will be smth strange otherwise -- Ата (talk) 19:21, 8 November 2013 (UTC)[reply]
Oppose proposal 3 edit
- Per my votes above. --Rschen7754 01:36, 14 October 2013 (UTC)[reply]
- Oppose--Jasper Deng (talk) 06:34, 14 October 2013 (UTC)[reply]
Per above. --AmaryllisGardener (talk) 16:33, 26 October 2013 (UTC)[reply]
- What do you mean by "per above"? No user here has brought up any arguments against this proposal, yet. Vogone talk 16:46, 26 October 2013 (UTC)[reply]
- I opposed proposal 1 and 2 that would merge the autopatrolled group into the autoconfirmed, so why would I support proposal 3 that abolishes the autopatrolled group? --AmaryllisGardener (talk) 14:03, 29 October 2013 (UTC)[reply]
- Because it makes no sense to keep this group in case 1 and 2 pass, does it? Vogone talk 14:06, 29 October 2013 (UTC)[reply]
- No it doesn't, but does it make sense to abolish it if 1 and 2 don't pass? --AmaryllisGardener (talk) 15:00, 29 October 2013 (UTC)[reply]
- No, and thus I didn't propose to do so. Vogone talk 15:02, 29 October 2013 (UTC)[reply]
- Ok, now I understand. I'll support now. --AmaryllisGardener (talk) 15:07, 29 October 2013 (UTC)[reply]
- No, and thus I didn't propose to do so. Vogone talk 15:02, 29 October 2013 (UTC)[reply]
- No it doesn't, but does it make sense to abolish it if 1 and 2 don't pass? --AmaryllisGardener (talk) 15:00, 29 October 2013 (UTC)[reply]
- Because it makes no sense to keep this group in case 1 and 2 pass, does it? Vogone talk 14:06, 29 October 2013 (UTC)[reply]
- I opposed proposal 1 and 2 that would merge the autopatrolled group into the autoconfirmed, so why would I support proposal 3 that abolishes the autopatrolled group? --AmaryllisGardener (talk) 14:03, 29 October 2013 (UTC)[reply]
- I opposed the second proposal. Legoktm (talk) 23:46, 26 October 2013 (UTC)[reply]
- Oppose I opposed the second proposal. StevenJ81 (talk) 19:00, 28 October 2013 (UTC)[reply]
- That said, I think it is clear that if (and only if) proposals 1 and 2 pass, there is not a reason to keep the autopatrolled group in existence. StevenJ81 (talk) 14:36, 29 October 2013 (UTC)[reply]
Proposal 4: merge rollback group to autopatrolled group or autopromote for rollback group edit
As I personally think that Wikidata has no need for a separated rollback group and don't think abusing rollback is more harm than abusing plain undo or TWINKLE rollback, I also propose to merge the rollback group to the autopatrolled group. If you prefer to keep these groups separated anyway, I also propose to introduce autopromotion for this user group as an alternative. The often quoted concerns that it isn't possible to provide edit summaries with rollback or that it is too easy to hit can easily be fixed with 1 line of JS in either the wiki's common.js or in the user's personal one. Especially since not many problems have occurred regarding edit wars, etc., on this wiki yet, I think such a step wouldn't be that unreasonable. Vogone talk 01:27, 14 October 2013 (UTC)[reply]
Support merge edit
- Vogone talk 01:27, 14 October 2013 (UTC)[reply]
- Glaisher [talk] 17:19, 14 October 2013 (UTC)[reply]
- --Steinsplitter (talk) 17:33, 20 October 2013 (UTC)[reply]
- --Base (talk) 16:02, 23 October 2013 (UTC)[reply]
- I have never understood the big deal behind reverting with one button [rollback] compared to (undo) and save. Ajraddatz (Talk) 19:47, 1 November 2013 (UTC)[reply]
Oppose merge; support autopromotion to rollbacker after 100 edits and a clean block log for accounts older than 14 days edit
- …
Oppose merge; support autopromotion to rollbacker after 250 edits and a clean block log for accounts older than 14 days edit
- …
Oppose merge; support autopromotion to rollbacker after 500 edits and a clean block log for accounts older than 14 days edit
- Weak support but it seems like a solution without a problem. --Rschen7754 01:39, 14 October 2013 (UTC)[reply]
- Aurora (talk) 14:03, 1 November 2013 (UTC)[reply]
Oppose merge; oppose autopromotion edit
- Support People should demonstrate that they know how to use rollback before they use it on a site where such use cannot be closely monitored. --Rschen7754 01:33, 14 October 2013 (UTC)[reply]
- Why? This is also not required for undo resp. TWINKLE rollback. Vogone talk 02:00, 14 October 2013 (UTC)[reply]
- Well, people can rollback a lot more quickly with the rollback tool; and global TWINKLE can always be forcibly taken away. --Rschen7754 02:47, 14 October 2013 (UTC)[reply]
- I don't think the speed is the point here. It's rather a question of intention. If you edit with bad intention it doesn't matter how quick and with which tools you do it. Vogone talk 02:56, 14 October 2013 (UTC)[reply]
- If Twinkle is added to the common.js here, it's not possible to edit Wikidata entries. (At least PiR's script has issues; I've experienced this myself.) --Glaisher [talk] 17:04, 14 October 2013 (UTC)[reply]
- I'm rewriting this script currently, but I don't understand why it wouldn't work here. πr2 (t • c) 00:08, 27 October 2013 (UTC)[reply]
- The API is very different. --Izno (talk) 15:12, 27 October 2013 (UTC)[reply]
- I'm rewriting this script currently, but I don't understand why it wouldn't work here. πr2 (t • c) 00:08, 27 October 2013 (UTC)[reply]
- If Twinkle is added to the common.js here, it's not possible to edit Wikidata entries. (At least PiR's script has issues; I've experienced this myself.) --Glaisher [talk] 17:04, 14 October 2013 (UTC)[reply]
- I don't think the speed is the point here. It's rather a question of intention. If you edit with bad intention it doesn't matter how quick and with which tools you do it. Vogone talk 02:56, 14 October 2013 (UTC)[reply]
- Well, people can rollback a lot more quickly with the rollback tool; and global TWINKLE can always be forcibly taken away. --Rschen7754 02:47, 14 October 2013 (UTC)[reply]
- Why? This is also not required for undo resp. TWINKLE rollback. Vogone talk 02:00, 14 October 2013 (UTC)[reply]
- Everyone doesn't want to be a rollbacker. --Stryn (talk) 04:46, 14 October 2013 (UTC)[reply]
- Rollback can be abused in edit warring. I do not support a proposal that removes the requirement of trust for the tool.--Jasper Deng (talk) 05:01, 14 October 2013 (UTC)[reply]
- (Sorry, I did not notice that I had !voted twice)--Jasper Deng (talk) 06:46, 14 October 2013 (UTC)[reply]
- Rollback can be abused in edit warring. I do not support a proposal that removes the requirement of trust for the tool.--Jasper Deng (talk) 05:01, 14 October 2013 (UTC)[reply]
- Well,I agree with Stryn. We can give people requesting it. --by ReviDiscussSUL Info at 06:10, 14 October 2013 (UTC)[reply]
- Rollback is, contrary to many opinions, abusable (such as edit warring with it), so I cannot support giving it out automatically.--Jasper Deng (talk) 06:35, 14 October 2013 (UTC)[reply]
- We also give out undo automatically. Is that not abusable? Vogone talk 06:49, 14 October 2013 (UTC)[reply]
- Edit warring is abuse of that, but at least for reverts you have the ability to set edit summaries so the user in question knows your position. With rollback the message is "you're a vandal and nothing else" - insulting.--Jasper Deng (talk) 07:51, 14 October 2013 (UTC)[reply]
- As I've written in the introduction to this section it is possible to enable optional summaries for rollback if needed. Vogone talk 16:54, 14 October 2013 (UTC)[reply]
- But rollback doesn't encourage summaries, and in most cases of its intended use, does not need it. When you rollback something that's not in your own userspace or your own edit, the message is "this is vandalism".--Jasper Deng (talk) 22:10, 14 October 2013 (UTC)[reply]
- As I've written in the introduction to this section it is possible to enable optional summaries for rollback if needed. Vogone talk 16:54, 14 October 2013 (UTC)[reply]
- Edit warring is abuse of that, but at least for reverts you have the ability to set edit summaries so the user in question knows your position. With rollback the message is "you're a vandal and nothing else" - insulting.--Jasper Deng (talk) 07:51, 14 October 2013 (UTC)[reply]
- We also give out undo automatically. Is that not abusable? Vogone talk 06:49, 14 October 2013 (UTC)[reply]
- no needed to merge --DangSunM (talk) 16:57, 14 October 2013 (UTC)[reply]
- There are users who are trusted enough for autopatrolled, but probably shouldn't get rollback. --Jakob (Scream about the things I've broken) 12:06, 15 October 2013 (UTC)[reply]
- Sceptical, rollback is a tool who is easy to misuse. I am also afraid that it would introduce many fat-finger-edits. With laptops, phones and ipads, to many rollbacks are fat-finger-edits today. -- Lavallen (talk) 05:56, 19 October 2013 (UTC)[reply]
- Rollback should only be given to users, who demonstrated to know what is and isn't vandalism. A certain number of edits and account age doesn't guarantee that. Armbrust (Local talk - en.WP talk) 10:33, 20 October 2013 (UTC)[reply]
- Per Stryn and Armbrust. --AmaryllisGardener (talk) 14:20, 25 October 2013 (UTC)[reply]
- Not everyone is able to use rollback properly. Matěj Suchánek (talk) 15:39, 30 October 2013 (UTC)[reply]
- Oppose merge Not all users want/need rollback. The Anonymouse (talk) 07:41, 7 November 2013 (UTC)[reply]
Proposal 5: supressredirect for rollbackers and property creators edit
A tool I miss here is the supressredirect. Since it's impossible for anybody to move in ns-0 it maybe is uncontroversial to add this right to some of the minor usergroups (RB and PC)? -- Lavallen (talk) 05:48, 19 October 2013 (UTC)[reply]
Support suppressredirect for both rollbackers and property creators edit
- -- Lavallen (talk) 16:08, 19 October 2013 (UTC)[reply]
- --GZWDer (talk) 04:03, 20 October 2013 (UTC)[reply]
- Wouldn't make any harm to give PCs access to it. Vogone talk 11:47, 20 October 2013 (UTC)[reply]
- --Steinsplitter (talk) 17:33, 20 October 2013 (UTC)[reply]
- Sometimes it is really needed. --Base (talk) 16:26, 22 October 2013 (UTC)[reply]
Support suppressredirect for rollbackers edit
I'd support that. Global rollbackers for example have that user right as well so that they can fix ill-considered page moves or just move pages which contain obvious misspellings etc. in a more effective way. Vogone talk 12:17, 19 October 2013 (UTC)[reply]
- --by ReviDiscussSUL Info at 14:58, 19 October 2013 (UTC)[reply]
- --DangSunM (talk) 21:04, 19 October 2013 (UTC)[reply]
- I do no see a reason what this has to do with the creation of properties. However, rollbackers could need that right. -- Bene* talk 21:12, 22 October 2013 (UTC)[reply]
Support suppressredirect for property creators edit
- …
Support suppressredirect as grantable right separately edit
I would firmly place myself in this category. I have a broad opposition to monolithic classes of users as it is difficult to deal with small breaches of trust in anything more than a "this is a big deal" fashion. I do see potential misuse of this tool (not much—moving things back is not hard), but do understand its usefulness, and so I would completely agree with allocation of the right separately from other rights.
Aside from that, let me respond to "global rollbackers have this" -> global rollbackers need to go through an RFA-like process, which we a) do not have here and which b) in fact, is almost completely orthogonal to the process here, which can be anything from a simple RFP with one admin responding to an admin out-of-the-blue handing out the right—this has the practical effect that rollback is handed out like candy to children. --Izno (talk) 16:13, 19 October 2013 (UTC)[reply]
- Weak support Since suppressredirect is useful but really doesn't have anything to do with rollback or property creator. The Anonymouse (talk) 07:44, 7 November 2013 (UTC)[reply]
Oppose proposal 5 edit
- Why? --Rschen7754 21:02, 19 October 2013 (UTC)[reply]
- Me for example, is guiding my bot by the content in some subpages to my userpage. If I move those subpages and add a
{{Delete}}
to the redirect-pages, it sometimes take several hours before the pages is deleted, and I can start the bot. -- Lavallen (talk) 06:57, 20 October 2013 (UTC)[reply]
- Me for example, is guiding my bot by the content in some subpages to my userpage. If I move those subpages and add a
- Oppose We currently do not receive much page-move vandalism and have a healthy amount of sysops.--Jasper Deng (talk) 06:56, 28 October 2013 (UTC)[reply]
Proposal 6: abusefilter-view-private for rollbackers edit
Previous discussion was Wikidata:Requests for comment/Abusefilter-view-private and abusefilter-log-private for rollbackers. zhwiki added Abusefilter-view-private right to rollbackers. (it is abusefilter-log-private) --GZWDer (talk) 14:29, 19 October 2013 (UTC)[reply]
Support proposal 6 edit
- My opinion on this matter hasn't changed at all. Vogone talk 14:53, 19 October 2013 (UTC)[reply]
I suppose. --Rschen7754 21:00, 19 October 2013 (UTC)[reply]
- Glaisher [talk] 10:37, 20 October 2013 (UTC)[reply]
- --Steinsplitter (talk) 17:33, 20 October 2013 (UTC)[reply]
- It can be useful for rollbackers and I see no possible harm that it may cause. --Base (talk) 15:47, 23 October 2013 (UTC)[reply]
- Weak support Rollbackers should be highly-trusted users, so that this would be something like reward. Also if they understand filters (as I do), they can help with improving. Matěj Suchánek (talk) 15:45, 30 October 2013 (UTC)[reply]
Oppose proposal 6 edit
- Nope, per my general opposition to monolithic classes. --Izno (talk) 16:14, 19 October 2013 (UTC)[reply]
- Stewards may not be happy with this as they wrote the filters. --Rschen7754 21:02, 19 October 2013 (UTC)[reply]
- --DangSunM (talk) 21:03, 19 October 2013 (UTC)[reply]
- --GZWDer (talk) 04:03, 20 October 2013 (UTC)[reply]
- Not needed. -- Bene* talk 21:12, 22 October 2013 (UTC)[reply]
- Per Izno.--Jasper Deng (talk) 06:57, 28 October 2013 (UTC)[reply]
- Can't see why it is needed. Ajraddatz (Talk) 19:48, 1 November 2013 (UTC)[reply]
- Oppose I don't see why rollbackers need that info. The Anonymouse (talk) 07:46, 7 November 2013 (UTC)[reply]
Proposal 7: new abusefilter manager user group edit
A suggestion is add a abusefilter manager group which has abusefilter-modify and abusefilter-log-private rights. However, It was rejected in zhwiki. --GZWDer (talk) 14:29, 19 October 2013 (UTC)[reply]
Support proposal 7 edit
- Support. --Izno (talk) 16:15, 19 October 2013 (UTC)[reply]
- I like such kind of groups. Trusted users who want to modify a filter aren't obliged to became sysops which obliges to do another stuff as well. --Base (talk) 15:52, 23 October 2013 (UTC)[reply]
- Weak support I find this alternative to becoming sysop only because of ability to manage filters. Matěj Suchánek (talk) 15:54, 30 October 2013 (UTC)[reply]
Oppose proposal 7 edit
- In my opinion unnecessary and we really don't need even more user groups than we already have. Vogone talk 14:53, 19 October 2013 (UTC)[reply]
- Adminship is easy enough to get here. --Rschen7754 19:50, 19 October 2013 (UTC)[reply]
- per Rschen7754--DangSunM (talk) 21:03, 19 October 2013 (UTC)[reply]
- per Rschen7754. Do not create so many user groups! ;-) -- Bene* talk 21:12, 22 October 2013 (UTC)[reply]
- Be a sysop instead! Lavallen (talk) 07:17, 23 October 2013 (UTC)[reply]
- It isn't as easy to became a sysop as you think and also why do you need to be forced to take unneeded obligations if you just want to modify filters? (I'm pretty sure that RfA for only modifying filters is to fail) --Base (talk) 17:00, 24 October 2013 (UTC)[reply]
- There are no such things as sysop-obligations as long as you are active, and I think we easily can add filtermodifications to the actions that would be counted as "sysop-activity". And I am not so sure that a RfA for only that purpose would fail. This project needs good filterdesigners, possibly more than any other wmf-project. But I fail to see the gain of a separate usergroup, with the entangled bureaucracy it would add. Since this project will become a multi-wikiculture-project, I see a large need of simplicity in the red tape. -- Lavallen (talk) 18:31, 24 October 2013 (UTC)[reply]
- It isn't as easy to became a sysop as you think and also why do you need to be forced to take unneeded obligations if you just want to modify filters? (I'm pretty sure that RfA for only modifying filters is to fail) --Base (talk) 17:00, 24 October 2013 (UTC)[reply]
- I could support this if and only if sysop became near-impossible to obtain.--Jasper Deng (talk) 06:58, 28 October 2013 (UTC)[reply]
- per Rschen7754. --AmaryllisGardener (talk) 16:08, 30 October 2013 (UTC)[reply]
- Oppose Users that would need to modify the abuse filter could just request adminship, since it is relatively easy to obtain. The Anonymouse (talk) 07:49, 7 November 2013 (UTC)[reply]
Proposal 8: add noratelimit and markbotedits rights to rollbacker edit
Noratelimit and markbotedits are also rights for global rollback, and user with noratelimit can rollback more then 100 times per minute. --GZWDer (talk) 14:29, 19 October 2013 (UTC)[reply]
Support both noratelimit and markbotedits for rollbackers edit
- --GZWDer (talk) 04:03, 20 October 2013 (UTC)…[reply]
- If one really want to fight with vandals fast why shall we limitate him? And sure no need to watch it in watchlist if you don't want. --Base (talk) 16:30, 22 October 2013 (UTC)[reply]
Support noratelimit for rollbackers edit
- …
Support markbotedits for rollbackers edit
- Makes sense for rollbackers but I doubt
noratelimit
will ever be needed here as long as this right is used in a proper way. Vogone talk 14:53, 19 October 2013 (UTC)[reply] - I don't think noeditlimit is
notnessasary. --by ReviDiscussSUL Info at 15:00, 19 October 2013 (UTC)[reply] - --DangSunM (talk) 21:01, 19 October 2013 (UTC)[reply]
- --Steinsplitter (talk) 17:33, 20 October 2013 (UTC)[reply]
Oppose proposal 8 edit
- Why? --Rschen7754 21:00, 19 October 2013 (UTC)[reply]
- I guess for the same reason why admins use the flood flag for mass deletions. Vogone talk 11:42, 20 October 2013 (UTC)[reply]
- No need. Please stop focusing on user rights so much.--Jasper Deng (talk) 03:36, 26 October 2013 (UTC)[reply]
- No need. --Stryn (talk) 14:05, 1 November 2013 (UTC)[reply]
- Per others. --AmaryllisGardener (talk) 14:27, 1 November 2013 (UTC)[reply]
- Oppose In my opinion, there isn't enough vandalism to justify either right. Also, a user can always get the flooder flag if absolutely necessary. The Anonymouse (talk) 07:52, 7 November 2013 (UTC)[reply]
Proposal 9: unwatchedpages for rollbackers and property creators edit
This one is pretty much not happening. |
---|
The following discussion has been closed by Izno. Please do not modify it. |
Can we add unwatchedpages right to some user groups like RB or PC? --GZWDer (talk) 14:29, 19 October 2013 (UTC)[reply] Support unwatchedpages for both rollbackers and property creators edit
Support unwatchedpages for rollbackers edit
Support unwatchedpages for property creators edit
Oppose proposal 9 edit
|
Proposal 10: abusefilter-log-private for rollbackers edit
Can we add abusefilter-log-private for rollbackers? zhwiki is already done.--GZWDer (talk) 04:02, 20 October 2013 (UTC)[reply]
Support proposal 10 edit
- --GZWDer (talk) 04:03, 20 October 2013 (UTC)[reply]
- Also here my opinion hasn't changed since the last discussion. Vogone talk 11:41, 20 October 2013 (UTC)[reply]
- --Steinsplitter (talk) 12:11, 20 October 2013 (UTC)[reply]
- Sure. --Base (talk) 15:54, 23 October 2013 (UTC)[reply]
- Glaisher [talk] 15:37, 30 October 2013 (UTC)[reply]
- Weak support However, this is useless without abusefilter-view-private rights (prop. 6). Matěj Suchánek (talk) 16:00, 30 October 2013 (UTC)[reply]
Oppose proposal 10 edit
- Why? --Rschen7754 04:09, 20 October 2013 (UTC)[reply]
- I think this is not nessesary.... and proposer didn't provided much,resonable reason, I think. --by ReviDiscussSUL Info at 04:16, 20 October 2013 (UTC)[reply]
- rollbackers can use it to anti-vandalism. discussion in zhwiki.--GZWDer (talk) 04:22, 20 October 2013 (UTC)[reply]
- As I know, there is not much antivandalism work on Wikidata,so that is not necessary. --by ReviDiscussSUL Info at 04:26, 20 October 2013 (UTC)[reply]
- rollbackers can use it to anti-vandalism. discussion in zhwiki.--GZWDer (talk) 04:22, 20 October 2013 (UTC)[reply]
- per Revi --DangSunM (talk) 13:56, 20 October 2013 (UTC)[reply]
- not needed, at least at the moment. -- Bene* talk 21:12, 22 October 2013 (UTC)[reply]
- Oppose I don't see why rollbackers need that info. The Anonymouse (talk) 07:53, 7 November 2013 (UTC)[reply]
Proposal 11: make a user right to override Spamblacklist edit
I think sometimes we needs to add links which is banned in m:Spam_blacklist or MediaWiki:Spamblacklist (current none), such as in TinyURL (Q1196499) and so on. We can add it to autopatrolled/rollback/PC group or create a new user group.--GZWDer (talk) 10:49, 21 October 2013 (UTC)[reply]
- And also see en:Category:Pages containing blacklisted links. There are already 3,964 page, in which we probably need to add blacklisted links.--GZWDer (talk) 10:56, 21 October 2013 (UTC)[reply]
Support proposal 11 edit
- …
Oppose proposal 11 edit
- No, we should not add blacklisted links to items that can be transcluded into the pages of WP etc. Instead, we should finetune the blacklisting made on meta. -- Lavallen (talk) 15:06, 21 October 2013 (UTC)[reply]
- I think Lavallen is right here. Vogone talk 15:53, 23 October 2013 (UTC)[reply]
- using such links may cause problems then. --Base (talk) 15:55, 23 October 2013 (UTC)[reply]
- --DangSunM (talk) 00:20, 24 October 2013 (UTC)[reply]
- No need.--Jasper Deng (talk) 06:59, 28 October 2013 (UTC)[reply]
- Neutral Better than going around blacklists is better managing such listing. Matěj Suchánek (talk) 16:07, 30 October 2013 (UTC)[reply]
- Could cause some chaos. -- Bene* talk 18:07, 31 October 2013 (UTC)[reply]
- --AmaryllisGardener (talk) 18:38, 31 October 2013 (UTC)[reply]
- Oppose Not necessary. The Anonymouse (talk) 07:55, 7 November 2013 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.