Wikimedia Bugzilla is closed!

[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...

In Comment 0 it is all nicely explained.

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.

This is pure sabotage the project sh wiktionary by Italian Stewards

I do agree with Vituzzu and Snowolf above.

I too believe that this request should be put on hold.

1) Above, it talks about Wikipedia users, though it talks about Wiktionary, so there is that uncertainty to remedy first, though it may be a slip of the tongue.

2) For a small wiki with 24 active users[1][2] to get 16 yes votes in the span of three-four days, when numbers of those users have next to nothing in the way of contributions, one has to and should question the validity of the process as representing the community will.

3) The site itself does not seem to have a clear requirement for patroller and person-bot rights.  Autopatrolled would seem to be sufficient to manage their requirements.  They are not a big wiki, and many of the big wikis don't do these things.  It has taken the wiki the best part of a week to get 500 edits, it does not seem that burdensome. You can allocate bot rights, and there doesn't seem to be the demonstrated need for person-bot rights in a review of your RC.

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, 
* Bot rights for people — the edits undertaken by you, could have been done by your bot. There is no example of how bot rights would be used by people, no bulk deletions, bulk moves etc. that would flood RC.
* Rollbacker —tThere is no evidence of "undo" required, nor to whom you would grant the right, especially as your active user list shows nobody except admins with more than 24 edits. Admins already have the right.
* Patroller — no evidence that it is needed (see rollbacker)
* Autopatrolled. This is a right that you should have admins and 'crats allocate, I believe that it is a good right to have the ability to self-manage.

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.

Reopened, added "community-consensus-needed" keyword.

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 = 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&aupr
> op=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.

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 = 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&aupr
> op=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.

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 ...

# 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
	),

(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 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

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 => true
> 
> I 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 => true
> > 
> > I 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 => true
> > > 
> > > I 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 
* NO requirement for FLOOD right, please do not grant it; the bot right has already been misused (and discussed elsewhere)
* NO requirement for other bot rights, beyond what currently exists as the default, please do not change these rights.
* NO requirement for ROLLBACK rights, please do not grant them

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 => true
> 
> I 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

https://gerrit.wikimedia.org/r/130362

Change 130362 merged by jenkins-bot:
Add autopatrolled group for shwiktionary

https://gerrit.wikimedia.org/r/130362