The users on sh.wikipedia.org reached a
consensus about the need for new user groups and recent changes patrol (see URL):
*Autopatroler
*Vraćač
*Patroler
*Korisnik bot
(In english: "Autopatrolled", "Rollbacker", "Patroller" and "Flood flag"
The voting was opened for 9 dayas (11.02.2014 - 14.02.2014) and nobody oposed to this. 16 same users supported all user group, very very high support.
$wgUseRCPatrol = true;
$wgFilterLogTypes = true;
Version: unspecified
Severity: normal
[Moving to "Wikimedia" product as this request is about settings / configuration of the website, not about the codebase of MediaWiki itself.]
$wgFilterLogTypes = true;
$wgFilterLogTypes is not a boolean... In any case the default should be fine for you.
(In reply to Bawolff (Brian Wolff) from comment #2)
$wgFilterLogTypes = true;
$wgFilterLogTypes is not a boolean... In any case the default should be fine
for you.
When will resolved this request?
(In reply to Kolega2357 from comment #3)
When will resolved this request?
Generally I would say allow 1-3 weeks. Various factors can effect that e.g. holidays, conferences, staff events and travel, whether or not a patch has been provided.
In this case there is not yet a patch so that would be the first thing to address.
Also, language is sometimes a barrier (we mostly can't read the on-wiki discussion to evaluate consensus, etc.) In this case Google translate fails to provide any hints (blank white page, no error msg).
(In reply to jeremyb from comment #4)
(In reply to Kolega2357 from comment #3)
When will resolved this request?
Generally I would say allow 1-3 weeks. Various factors can effect that e.g.
holidays, conferences, staff events and travel, whether or not a patch has
been provided.In this case there is not yet a patch so that would be the first thing to
address.Also, language is sometimes a barrier (we mostly can't read the on-wiki
discussion to evaluate consensus, etc.) In this case Google translate fails
to provide any hints (blank white page, no error msg).
I am not use Google Translate.
(In reply to Kolega2357 from comment #5)
I am not use Google Translate.
So? I did (try to). I can't read the discussions linked from comment #0 without some translation help...
About an half voters have no other (than votes themselves) contribs on that wiki.
Those instruments are definitely an overkill for a wiki with, by now, a very very slow recentchanges' page.
Since we already had lots of troubles from a poor flags-management (namely hi.wiki's) case and that discussion has been definitely canvassed I suggest to suspend fulfilling this request for at least ~6 months.
(In reply to Vituzzu@it.wiki from comment #8)
About an half voters have no other (than votes themselves) contribs on that
wiki.Those instruments are definitely an overkill for a wiki with, by now, a very
very slow recentchanges' page.Since we already had lots of troubles from a poor flags-management (namely
hi.wiki's) case and that discussion has been definitely canvassed I suggest
to suspend fulfilling this request for at least ~6 months.
This is probably incorrectly. The community has voted for new user groups and recent changes patrolling.
(In reply to Kolega2357 from comment #9)
(In reply to Vituzzu@it.wiki from comment #8)
About an half voters have no other (than votes themselves) contribs on that
wiki.Those instruments are definitely an overkill for a wiki with, by now, a very
very slow recentchanges' page.Since we already had lots of troubles from a poor flags-management (namely
hi.wiki's) case and that discussion has been definitely canvassed I suggest
to suspend fulfilling this request for at least ~6 months.This is probably incorrectly. The community has voted for new user groups
and recent changes patrolling.
People with no edits setting apart from those votes? You have been canvassing for these changes for weeks.
I did not canvassing, that you should not care who I invited to vote and it is not your thing.
(In reply to Kolega2357 from comment #11)
I did not canvassing, that you should not care who I invited to vote and it
is not your thing.
If I'm not misreading the comment, you just admitted to canvassing.
I too believe that this request should be put on hold.
Re Kolega's comments. One of the reasons that there are stewards is to look to assist communities with the application of rights. The history of rights allocations has been problematic when they are over-allocated to small communities, and the control of a few people. We see things become about ownership. Rights that grow organically and naturally with the community have seem to be that have worked best. Rather than rights thought to be a good idea to make a community or the bureaucrats seem to justify their positions and elevate a level of unnecessary importance.
[1] https://bitly.com/1gFTXaf+ (small wiki info)
[2] https://sh.wiktionary.org/w/api.php?action=query&list=allusers&auactiveusers&auwitheditsonly&aulimit=500&auprop=editcount
For the record, Google translate this proposal as
Suggest to sh.wiki introduce the following user groups:
autopatroleri - any article offices, the records will show that they are automatically view changes - this could be confirmed automatically active users
patroleri - patrolling recent changes (and may be the first step towards obtaining the status of a later administrator)
vraćači (rollbackeri) - return all changes with one click.
user bot (flood flag) - every administrator and bureaucrat can assign yourself or another user to perform routine tasks
Serbo Wiki exceeded the number 40,000 article and think that this could benefit the project in the future. Serbo-Wiki is the largest South Slavic vocabulary with over 40,000 articles. It would be best to make a statement about this - Kolega2357 (talk) 20:16, 11 February-February 2014 (UTC)
I'm making this as not done per the canvassing issues.
What we're worried here is a repeat of something akin to hiwiki, where users with sysop rights sought to create a lot of permissions (compared to the number of active users) to limit access to sysop. The mere request is not necessarily a bad thing, but the admitted canvassing, especially coupled with recent issues involving Kolega and steward requests, I think are worrying.
Canvassing makes it impossible to figure out whether a request has legitimate community support. If you couple this with the fact that the wiki has barely 10 active users and a bot that's creating stubs automatically on a massive scale (106k edits in the last 30 days), we're very, very close to what hiwiki was at the time of the RfC. I am very worried by how things are going on there.
My comment to the proposal is that with rights there should be a clear demonstration about what the rights do, how they would be used, and the effect on the wiki. The practice should be demonstrate the benefit, and demonstrate the use, have that conversation on wiki, and it should be a clear question answer.
Rights are not about making statements, rights are not about prestige, they are simply tools to be used to undertake tasks when those tasks need to be undertaken.
In checking your RC,
I propose that this be reopened, with solely the autopatrolled right be configured to be activated.
(In reply to billinghurst from comment #19)
I propose that this be reopened, with solely the autopatrolled right be
configured to be activated.
Not patroller too?
Rollbacker is reviewing others edits, there seems no such evident experience from the active editors, or the RC, so use of undo is sufficient. Would not seem that there is enough active users with sufficient editing experience to make that decision. Admins already have it. It is only a one step permission versus a two step. What are you seeing different?
This is extremely incorrect stroke by Wikimedia Stewards. I believed all Stewards, but do not believe individuals. You cut the branch on which you sit.
Shoot the messenger! Your argument more equates to "I don't like it"
Please support your statements with factual evidence, demonstrations of inaccuracy of the statements, or a clear descriptive explanation of how the proposed changes are for the extended benefit of the community, how they will be used, etc.
Stewards reviewed this and do not believe that there is a community consensus, nor that the community has sufficient active users to reach such a valid consensus, especially when based upon a conversation based on patriotic competition rather than a demonstrated need.
Server: sh.wiktionary.org
No. of pages: 850,497
No. of articles: 849,245
No. of edits: 1,301,882
No. of users: 1,591
No. of active users: 16 (and noting that 4 of these are bots)
No. of group:autopatrolled: 0
No. in group:sysop: 5
No. in group:bureaucrat: 3
No. in group:oversight: 0
No. in group:checkuser: 0
No. in group:bot = 10
and if you have a look at the recent edit count
https://sh.wiktionary.org/w/api.php?action=query&list=allusers&auactiveusers&auwitheditsonly&aulimit=500&auprop=editcount
shows that all users that require the rollback right, have it, there is no demonstrated need. They would be well suited to implement an autopatrolled right.
(In reply to billinghurst from comment #25)
Stewards reviewed this and do not believe that there is a community
consensus, nor that the community has sufficient active users to reach such
a valid consensus, especially when based upon a conversation based on
patriotic competition rather than a demonstrated need.Server: sh.wiktionary.org
No. of pages: 850,497
No. of articles: 849,245
No. of edits: 1,301,882
No. of users: 1,591
No. of active users: 16 (and noting that 4 of these are bots)
No. of group:autopatrolled: 0
No. in group:sysop: 5
No. in group:bureaucrat: 3
No. in group:oversight: 0
No. in group:checkuser: 0
No. in group:bot = 10and if you have a look at the recent edit count
https://sh.wiktionary.org/w/api.
php?action=query&list=allusers&auactiveusers&auwitheditsonly&aulimit=500&aupr
op=editcountshows that all users that require the rollback right, have it, there is no
demonstrated need. They would be well suited to implement an autopatrolled
right.
Can only autopatroler group for sh wiktionary?
(In reply to billinghurst from comment #25)
Stewards reviewed this and do not believe that there is a community
consensus, nor that the community has sufficient active users to reach such
a valid consensus, especially when based upon a conversation based on
patriotic competition rather than a demonstrated need.Server: sh.wiktionary.org
No. of pages: 850,497
No. of articles: 849,245
No. of edits: 1,301,882
No. of users: 1,591
No. of active users: 16 (and noting that 4 of these are bots)
No. of group:autopatrolled: 0
No. in group:sysop: 5
No. in group:bureaucrat: 3
No. in group:oversight: 0
No. in group:checkuser: 0
No. in group:bot = 10and if you have a look at the recent edit count
https://sh.wiktionary.org/w/api.
php?action=query&list=allusers&auactiveusers&auwitheditsonly&aulimit=500&aupr
op=editcountshows that all users that require the rollback right, have it, there is no
demonstrated need. They would be well suited to implement an autopatrolled
right.
Since the request for autpatrolled is valid (though community consensus is needed) according to you, I don't see how this bug is a WONTFIX …
At this point, the bug request to me appears to be for the multiple items, so if there is a change to the bug request to the autopatrolled only, I would feel that it would be considered acceptable. There would be the need to identify who can assign autopatrolled status, is it 'crats, or admins and crats, that has not been identified in this request.
(In reply to billinghurst from comment #28)
At this point, the bug request to me appears to be for the multiple items,
so if there is a change to the bug request to the autopatrolled only, I
would feel that it would be considered acceptable. There would be the need
to identify who can assign autopatrolled status, is it 'crats, or admins and
crats, that has not been identified in this request.
I am agree with you for autopatrolled status. Can for the Autopatroll group adding and removing bureaucrats and administrators?
Do autopatrollers can have rollback and patrol right?
(In reply to Kolega2357 from comment #29)
(In reply to billinghurst from comment #28)
At this point, the bug request to me appears to be for the multiple items,
so if there is a change to the bug request to the autopatrolled only, I
would feel that it would be considered acceptable. There would be the need
to identify who can assign autopatrolled status, is it 'crats, or admins and
crats, that has not been identified in this request.I am agree with you for autopatrolled status. Can for the Autopatroll group
adding and removing bureaucrats and administrators?Do autopatrollers can have rollback and patrol right?
It shouldn't be a problem to assign any of these two rights to that group but it would require consensus. About who can add/remove users to the group as well as about whether that group should include additional "minor" rights which every non-vandal should be allowed to use. If you can link to an onwiki discussion where these two issues were discussed this bug can be fulfilled, I guess.
There is neither need nor call for a separate rollback group, let alone candidates. Just do the autopatrolled, and allow it to be added & removed by administrators. That discussion exists at sh.wiktionary.
The only other thing that you may wish to consider is the patrol right itself, and who can patrol others edits. You may wish to have that assigned to this group, or you may wish to consider that this is a right that can be more generic.
$wgGroupPermissions['autopatrol']['autopatrol'] = true;
$wgGroupPermissions['autopatrol']['rollback'] = false;
$wgGroupPermissions['autopatrol']['patrol'] = false; (for patrolling new pages)
Can this?
I believe that the additions would be ...
// Miscellaneous ...
'shwiktionary' => array(
'autopatrolled' => array( 'autopatrol' => true ), // bug 61380
),
There is no need to list the false if they align with the default.
'+shwiktionary' => array(
'bureaucrat' => array( 'autopatrolled' ), 'sysop' => array( 'autopatrolled' ), // bug 61380
),
'+shwiktionary' => array(
'bureaucrat' => array( 'autopatrolled' ), 'sysop' => array( 'autopatrolled' ), // bug 61380
),
(In reply to billinghurst from comment #34)
I believe that the additions would be ...
groupOverrides ...
// Miscellaneous ...
'shwiktionary' => array(
'autopatrolled' => array( 'autopatrol' => true ), // bug 61380),
There is no need to list the false if they align with the default.
wgAddGroups @{ ...
'+shwiktionary' => array(
'bureaucrat' => array( 'autopatrolled' ), 'sysop' => array( 'autopatrolled' ), // bug 61380),
wgRemoveGroups @{ ...
'+shwiktionary' => array(
'bureaucrat' => array( 'autopatrolled' ), 'sysop' => array( 'autopatrolled' ), // bug 61380),
Super good idea.
'shwiktionary' => array(
'autopatrolled' => array( 'autopatrol', 'patroller', 'rollbacker', => true ), // bug 61380),
Really?
(In reply to Kolega2357 from comment #35)
(In reply to billinghurst from comment #34)
'shwiktionary' => array(
'autopatrolled' => array( 'autopatrol', 'patroller', 'rollbacker', => true ), // bug 61380),
Really?
*If* you really decide to let autopatrollers using the patrol and the rollback right you would need to add:
'shwiktionary' => array(
'autopatrolled' => array(
'autopatrol' => true, 'patrol' => true, 'rollback' => true,
), // bug 61380
),
Anyway, this is done by the developers and would require consensus onwiki beforehand (though I did not check yet whether that is currently the case).
(In reply to billinghurst from comment #21)
Rollbacker is reviewing others edits, there seems no such evident experience
from the active editors, or the RC, so use of undo is sufficient.
Undo requires the patroller to manually mark the reverted edit(s) as patrolled in order to clear them from the unpatrolled backlog. The native rollback feature does this automatically.
I recommend against creating a group that has all four rights. However creating them as two groups makes sense:\
Use: People who participate in reviewing edits
and dealing with vandalism.
patrollers => // like on dawiki
patrol => true autopatrolled => true rollback => true
Use: People who don't need their edits reviewed
but are not aware, or interested in, the patrol system.
autopatrol => // like on dawiki,
autopatrolled => true
Use: Temporarily granted to users who
are performing non-controversial maintenance of some kind.
flood =>
bot => true
(In reply to Krinkle from comment #37)
(In reply to billinghurst from comment #21)
Rollbacker is reviewing others edits, there seems no such evident experience
from the active editors, or the RC, so use of undo is sufficient.Undo requires the patroller to manually mark the reverted edit(s) as
patrolled in order to clear them from the unpatrolled backlog. The native
rollback feature does this automatically.I recommend against creating a group that has all four rights. However
creating them as two groups makes sense:\Use: People who participate in reviewing edits
and dealing with vandalism.
patrollers => // like on dawikipatrol => true autopatrolled => true rollback => trueUse: People who don't need their edits reviewed
but are not aware, or interested in, the patrol system.
autopatrol => // like on dawiki,autopatrolled => trueUse: Temporarily granted to users who
are performing non-controversial maintenance of some kind.
flood =>bot => true
I am agree with
Use: People who participate in reviewing edits
and dealing with vandalism.
patrollers => // like on dawiki
patrol => true autopatrolled => true rollback => true
I forgot markbotedits => true.
patrollers => // like on dawiki
patrol => true autopatrolled => true rollback => true markbotedits => true
(In reply to Kolega2357 from comment #39)
I forgot markbotedits => true.
patrollers => // like on dawiki
patrol => true autopatrolled => true rollback => true markbotedits => true
I don't think "markbotedits" is recommended...
(In reply to Trijnstel from comment #40)
(In reply to Kolega2357 from comment #39)
I forgot markbotedits => true.
patrollers => // like on dawiki
patrol => true autopatrolled => true rollback => true markbotedits => trueI don't think "markbotedits" is recommended...
If it is abused "markbotedits" Such users will be sanctioned.
(In reply to Kolega2357 from comment #41)
(In reply to Trijnstel from comment #40)
(In reply to Kolega2357 from comment #39)
I forgot markbotedits => true.
patrollers => // like on dawiki
patrol => true autopatrolled => true rollback => true markbotedits => trueI don't think "markbotedits" is recommended...
If it is abused "markbotedits" Such users will be sanctioned.
That's not what I mean. With "markbotedits" the edits done via rollback are hidden on the recent changes. And that's certainly not recommended.
(In reply to Trijnstel from comment #42)
(In reply to Kolega2357 from comment #41)
(In reply to Trijnstel from comment #40)
(In reply to Kolega2357 from comment #39)
I forgot markbotedits => true.
patrollers => // like on dawiki
patrol => true autopatrolled => true rollback => true markbotedits => trueI don't think "markbotedits" is recommended...
If it is abused "markbotedits" Such users will be sanctioned.
With "markbotedits" the edits done via rollback are hidden on the recent changes. And that's certainly not recommended.
With "markbotedits" the edits done via rollback are hidden on the recent changes. And that's certainly not recommended. >>>> Yes I am know for this.
I follow a sh wiktionary. It not "markbotedits" will make a problem
<sigh> This request keeps becoming a pie and chips and peas and gravy and tabasco and ... This is a small wiki with the only regularly active contributors being the administrators (already with the rights), it does not need a long string of rights changes. That a 'crat seemingly believes that he needs more boxes to tick, that more boxes seemingly adds more credibility and more prestige, is not a sufficient reason to make changes. Rights changes should be made to address needs only, and as needs grow then more rights can be added incrementally as the community matures.
There are other issues that have been addressed elsewhere about some of the decision-making at this wiki, so I am requesting that we keep the changes simple and transactional, not extensive and transformational.
The shwiktionary community is very small, such there there is
As I said above, about the only other right that would seem to be appropriate would be the patrol right, and how that is managed. At this stage, it needs that mature and scoped conversation in the community that properly explains the right and how it could be used, and at this stage, that has not been had, well not as I would see as satisfactorily undertaken. All that is there is a "rah! rah! We deserve more rights, what do you think?" and all the hands went up and said "yes"; in my opinion, naive and unsatisfactory.
That it was proposed in such a matter by the 'crat, and closed by the 'crat and then brought here by the same 'crat, and then repeatedly extended by the 'crat (who in my opinion has demonstrated poor judgement and practice at the wiki), is of great concern to me as a steward. So again I ask that the rights changes are kept to being minimal and incremental.
(In reply to Trijnstel from comment #40)
(In reply to Kolega2357 from comment #39)
I forgot markbotedits => true.
patrollers => // like on dawiki
patrol => true autopatrolled => true rollback => true markbotedits => trueI don't think "markbotedits" is recommended...
Though I still see no attempt to gain community consensus for all the further changes suggested, I just wanted to note that "markbotedits" is a right which all e. g. global rollbackers do have. I don't see why it shouldn't be recommended as usually, unless the API is used to perform an edit, no bot=1 is set to the edit.
Looking this bug over - I see a strong view by Stewards in regards to right management and which rights are needed on wiki. While I appreciate it, said decisions are not solely a stewards' responsibility.
Listening to what was said however, I am going to patch Autopatrolled only per a need and a small consensus for the community. This will match other communities Autopatrolled rights. If you want to assign rollback etc. to Autopatrolled, please open another local discussion involving *only* community members, zero canvassing. On a note, one or two supports is enough to get a feature implemented, canvassing to get 16 votes is the issue here not numbers.
Change 130362 had a related patch set uploaded by John F. Lewis:
Add autopatrolled group for shwiktionary