Meta talk:Flood flag/Archives/2008-09

First comments

I'd be really interested in hearing about what the community thinks about this function, and whether or not we'd be able to derive consensus as to whether we should send a request to Bugzilla about this or not. ----Anonymous Dissident^Talk 02:43, 9 August 2008 (UTC)

I think this is a great idea with relatively little drawbacks, if at all. Cirt 02:52, 9 August 2008 (UTC)

I hope this is for Meta only (as a test), since in bigger wikis it may have repercussions but really, its a brilliant idea to delete multiple pages/or block multiple proxies..--Cometstyles 02:57, 9 August 2008 (UTC)

Yup, I was thinking that it would only be a local function here on meta for now, to see how it goes for a bit. --Anonymous Dissident^Talk 02:59, 9 August 2008 (UTC)

Umm, we can already do this by allowing admins to grant and remove bot rights from themselves. That would mean the rights changes are logged, limiting the potential for abuse. I have no issues with having the proposal implemented in this manner. Not so sure about implementing it in any other manner though.  — Mike.lifeguard | ^@en.wb 03:01, 9 August 2008 (UTC)

$wgGroupPermissions['flood']['bot']             = true; #creates the "flood" group with the "bot" right
$wgGroupsAddToSelf['sysop'] = array('flood');           #sysops may add the "flood" group to themselves
$wgGroupsRemoveFromSelf['sysop'] = array('flood');      #sysops may remove the "flood" group from themselves
$wgRemoveGroups['bureaucrat'] = array(
 'flood',                                               # only this line is new; it lets bureaucrats remove the "flood" group from users
 'ipblock-exempt',
 'bot',
 'sysop',
 'bureaucrat');

We would need to clarify when, if at all, a separate (permanent) bot account is needed, rather than using your own account with +bot. I'm not sure if I have an opinion on that yet, or what it might be.  — Mike.lifeguard | ^@en.wb 03:07, 9 August 2008 (UTC)

I like this idea. Sometimes I have to revert my misbehaving child bot and flooded the RC with tonnes of reverts. OhanaUnited^{Talk page} 03:57, 9 August 2008 (UTC)

In regards to allowing admins to bot flag themselves: I think this would be a rather cheap solution. It'd result in a lot of log changes and such, when the flood flag could be simply ticked and unticked. Plus, an admin does not really become a bot when they flood RC, so flagging themselves as a bot could cause confusions and inaccuracies. Plus, it'd temporarily add them to the bot user class, which could again cause confusion. --Anonymous Dissident^Talk 05:36, 9 August 2008 (UTC)

I don't think it'd be a good idea to do this without having something logged (eg. "Bob turned flood flag on" in RC), so if it can be done Mike's way that'd probably be the best, IMO. —Giggy 05:44, 9 August 2008 (UTC)

If you read the third section of the proposal, it is stated that a log action would be recorded on the (de-)activation of the flood flag. --Anonymous Dissident^Talk 06:31, 9 August 2008 (UTC)

To Mike. I recall that Pathoschild denied to flag him as bot around his flooding edits. He claimed he had done those edits with hands, so it had been really no bot editing, and it shouldn't. I personally take it trivial, but I can understand this sentiment for the sake of definition and dignity of human being. Some would agree with him. Others not. And for the former, flood flag would be a solution. --Aphaia 06:15, 9 August 2008 (UTC)

I honestly don't see the need for this; if it really is needed on a temporary basis, the bot flag would be fine.

James F. (talk) 14:38, 9 August 2008 (UTC)

But then it needs to be removed, and re-added and that clogs a user's access logs. A tickable box is also much more user-friendly. Getting bot-flagged would be a pain for some people who regularly flood RC; if it were simple to get a bot flag, I'm sure they would every time they want to flood RC. With this, they can switch the flag on and they're ready to go. --Anonymous Dissident^Talk 14:45, 9 August 2008 (UTC)

I agree and disagree this proposes at the same time. It would be benefit if administrators can hide some edits, but what about the others? I think sysops should not have ability to hide their edits if they want to, it would be best if they can have a tick-box like minor edit. So, sysops can hide edits that they want to be hidden. --Passawuth 15:03, 9 August 2008 (UTC)

If I'm not wrong, sysops are already allowed to mark their edits as "bot" by touching the URL a bit, manually. What this request is proposing is to make this process much easier. Even if this is turned down, I guess a small gadget can solve this issue. So in the end, this can be like deciding between whether we need this feature in MediaWiki, or we need it as a gadget. I would vote for the first one. Huji 16:53, 9 August 2008 (UTC)

The bot=1 URL parameter works for rollbacks only. On the other hand, bots can use bot=0, so you could just set up a new user group, give it bot rights, and add a "bot mode" checkbox to the editing interface through a javascript gadget. --Tgr 09:15, 10 August 2008 (UTC)

I support this idea, it's easier than finding a 'crat (or steward) to flip the bot flag on and off. I do think there is merit in having the flag setting recorded somewhere (as suggested, to recent changes log, in lieu of the actual changes, once when it goes on, and again when it goes off). Currently preference changes are not logged but since this presumably will require development, maybe that's not that big a deal. ++Lar: t/c 17:05, 9 August 2008 (UTC)

Sorry, I don't understand the difference between having a tick box in your preferences with a log entry and my suggestion above of using a pre-existing feature which was intended specifically for this purpose. Why do we need another solution to replace one that works perfectly?  — Mike.lifeguard | ^@en.wb 17:30, 9 August 2008 (UTC)

If your implementation gives the same effect (flippable by the admin, the flips are logged) except that the logging isn't in recent changes, but instead are in the permissions log (which is the difference between these, I think)... that's cool by me. I'm more about the general notion here ... of avoiding floods being a good idea, than the exact implementation details... (however I DO think there is some slight utility to having the flip logged in recent changes... it's an odd thing to do since it's a permissions thing but I do think so) ++Lar: t/c 05:27, 10 August 2008 (UTC)

I think this is of interest to the community on my local project at en wiki, I've posted a note there. NonvocalScream 17:57, 9 August 2008 (UTC)

How is it? This is a feature for wikis that want it. Enwiki won't want it. They shot down global admins, and will shoot this down now if we aren't careful, even though it's no business of theirs. Majorly ^talk 22:45, 9 August 2008 (UTC)

@Huji: I've already written a JavaScript snippet for this: it's in wikipedia:it:Utente:Pietrodn/monobook.js. This script shows a link in user contributions pages which adds and removes sorry, that's not correct --Pietrodn · talk with me 20:53, 11 August 2008 (UTC) the "&bot=1" parameter from the URL and reloads the page. You can implement it as a gadget if you want. --Pietrodn · talk with me 20:49, 11 August 2008 (UTC)

Accountability

This is a bad idea in my opinion. I want to be able to have visability if somone is going around making many edits at once. I want to see it in my recent changes feed. Where is accountability aside from the log action of enable/disable flag? Basically, I need to see the flood so that if there is disruptive of destructive edits en mass, they can be stopped. NonvocalScream 17:44, 9 August 2008 (UTC)

Well, they would be bot edits, right? The same records are kept as normal. Furthermore, admins can (or should be! and on Meta I'd say they definitely are) trusted to not make disruptive edits. If you cannot trust your administrators to not make disruptive edits, you have a more pressing concern.  — Mike.lifeguard | ^@en.wb 18:05, 9 August 2008 (UTC)

En.wiki's current standards for bot-like editing are pretty high, so I don't think I would support enabling this there. Christopher Parham (talk) 18:43, 9 August 2008 (UTC)

That has little to no relevance here - discuss enwiki issues on enwiki please.  — Mike.lifeguard | ^@en.wb 19:02, 9 August 2008 (UTC)

Indeed, telling this to enwiki was completely unnecessary, as there is not a chance in hell that this would be implemented there. Here, where we generally are more laid back and mellow, we can consider of working out something that will be highly useful. Majorly ^talk 22:44, 9 August 2008 (UTC)

Mike was not talking to me, he was talking to the one who mentioned it to en wiki. Additionally, telling it to en wiki was ok, they are interested, and this is meta.

(ec)No, they wouldn't be like bot edits - but they should be. Bot edits can be filtered out (hidden) at the discretion of an individual editor. If an editor wants to see edits with a "b" flag, he/she can, just as he/she can hide or not hide edits marked as "m" (minor). But (as currently proposed) edits tagged as "flood" won't be visible - period. To establish accountability, flood edits should show up as "f" in the recent changes list, and editors should have a choice - as they do with bots - to filter these out (hide them). John Broughton 18:46, 9 August 2008 (UTC)

That's what I am proposing. They'd by default be filtered from RC, but an especially observant RC watcher may be interested in watching the flood flag edits, and that'd be opt-in. --Anonymous Dissident^Talk 03:31, 10 August 2008 (UTC)

Agree with anonadis, I think they should be able to watch them in RC. I'm not opposed to a flag, but I do want a way to see them in the feed. NonvocalScream 03:39, 10 August 2008 (UTC)

I'm proposing that we actually use the bot flag and the settings provided above, as this is what these are intended for. That avoids the issues you mention, and was suggested specifically for those reasons.  — Mike.lifeguard | ^@en.wb 19:02, 9 August 2008 (UTC)

I like this solution, this gives the ability to filter for the user, instead of the ability to filter to the flooder, so concerned editors can still see the flood edits. Do not forget that the nature of the feature request and the implementation has effects on many projects who might decide to use the feature. So make it usable. NonvocalScream 19:24, 9 August 2008 (UTC)

I think you still misunderstand - this is not a feature request. (This exists already in core software; we are discussing whether to enable it or not on Meta. Other wikis may do the same. If the software doesn't do what they want it to, they can submit a request to bugzilla.)  — Mike.lifeguard | ^@en.wb 19:46, 9 August 2008 (UTC)

Indeed. There's no need to be terrified this will get implemented onto enwiki. It won't. <touch wood> No admin has ever gone rogue here, and I don't expect they will. They have, and will have rogue admins on enwiki. Please don't bring your issues here, it's tiresome when we're trying to implement a useful feature for our project. Majorly ^talk 22:44, 9 August 2008 (UTC)

Again, I never mentioned this to en wiki, I'm referring to enabling on meta. Thanks, NonvocalScream 01:29, 10 August 2008 (UTC)

John Broughton, showing bot edits on RC would also show admin flood edits. The fact of naming it flood doesn't change that they're basically doing the same (maybe we should change the name of the link at RecentChanges if enough people complain). Platonides 22:00, 10 August 2008 (UTC)

I imagine that is a system message that we can change to "show bot and flood entries" or somesuch.  — Mike.lifeguard | ^@en.wb 00:08, 11 August 2008 (UTC)

Good idea

This is a good idea. This is very much needed for our project. I'm not interested in the slightest in what English Wikipedians think of it. This isn't going to be implemented there. I have, in the past had to flag people who have been flooding recent changes for various reasons, so that it is usable to other users. It would be better, and simpler for them to be able to flag themselves. Admins here are generally trusted across many projects, so there won't be abuse. If you suspect abuse, change your recent changes to show flagged edits. It's that simple. Majorly ^talk 22:53, 9 August 2008 (UTC)

I think its a bad idea, as a meta contributor of course. NonvocalScream 01:29, 10 August 2008 (UTC)

Support Under conditions:

Personally I feel this would be the best implementation of this:

$wgGroupPermissions['flood']['bot']             = true; #creates the "flood" group with the "bot" right
$wgGroupsAddToSelf['sysop'] = array('flood');           #sysops may add the "flood" group to themselves
$wgGroupsRemoveFromSelf['sysop'] = array('flood');      #sysops may remove the "flood" group from themselves
$wgRemoveGroups['bureaucrat'] = array(
 'flood',                                               # only this line is new; it lets bureaucrats remove the "flood" group from users
 'ipblock-exempt',
 'bot',
 'sysop',
 'bureaucrat');

That would do the following:

• Create a flood usergroup with recent changes hidden by default
• Allow Sysops to add and remove this right from any user
• Allow users with the flag to remove it, without asking a sysop.

So... Other users who are planning to flood rc, can ping a sysop for the flag, then remove it from themselves.

Thanks all, Mww113 23:05, 9 August 2008 (UTC)

...the way you are doing it is exactly the same as we handle "bots". It's pointless, let's just go with Mike's... Cbrown1023 talk 23:29, 9 August 2008 (UTC)

Agree. Seems like a good idea for Meta. —Giggy 01:14, 10 August 2008 (UTC)

For meta, Mike's idea sounds like a winner; for enwiki (if, somehow, it's implemented there), Mww113's would be ideal. —Animum (talk) 01:21, 10 August 2008 (UTC)

As we have already pointed out, this will never be implemented on emwiki. Mww113 11:51, 10 August 2008 (UTC)

Aye, hence the "(if, somehow..." part. ;-) —Animum (talk) 17:48, 17 August 2008 (UTC)

Why this is different (and better) than a bot flag

Let me highlight the differences, for everyone:

1. Bot flags being turned on and off clog a user's user rights log, this does not.
2. Assigning a bot flag is much more time consuming that running up to prefs and ticking a box.
3. It actually results in inaccuracies, because if someone looks in here, they'll see a user that is typically not a bot listed there. This is confusing and has the potential to cause misconceptions, especially if a job goes for, say, four or five hours, or if a user wants to go to bed and get up the next morning to complete a job; this leaves a gaping window for this confusion.
4. It'd be a pain asking someone to assign a bot flag every time one wants to do this, for the requester and the assigner.
5. Even if we allow admins to assign their own flags, the problem of number two become relevant.

I hope this clears everything up. This is not a mimic of the bot flag; the bot flag is a user-right, this is a tool. --Anonymous Dissident^Talk 01:27, 10 August 2008 (UTC)

It should be a rights change - we are supposed to keep a log of everything that takes place on the wiki. "Clutter" of the logs is not a problem.

Assigning the bot flag is absolutely not difficult or time-consuming to do; this is a silly statement.

If you have assigned yourself the bot flag, you are a bot - I don't see how confusion would arise from that. The log would then give details for why the user is listed as a bot. If this is actually a concern, we may easily have a "flood" group with the same rights as bot to differentiate the groups.

This allows admins to give themselves the bot flag and remove it from themselves (ie using Special:Userrights) No request needed.

I think your proposal is going about this the wrong way - there is no need to reinvent the wheel. We have this in core software for a reason.  — Mike.lifeguard | ^@en.wb 04:36, 10 August 2008 (UTC)

The other thing is that tasks which are long-running should perhaps be done with a separate account.  — Mike.lifeguard | ^@en.wb 04:37, 10 August 2008 (UTC)

Bots are usually trusted to be automated or semi-automated accounts, and with the flood flag, this is not always the case. What is silly to assert is that one becomes a bot when they are assigned the bot flag. Technically, perhaps, but not truly. And no it shouldn't be a rights change. If I turn popups on or off, should that be recorded? No. Same with other gadgets. Plus, a log of the switching on and off of the flood flag would be recorded. And assigning a bot flag is comparatively more time consuming than ticking a box, and this is increased massively if one needs to request the flag. Whether long-running tasks should be done with a separate account is, as far as I know, a matter of choice. Even with a different account, the user is still not a bot. --Anonymous Dissident^Talk 05:32, 10 August 2008 (UTC)

I don't know what you're doing to make granting a bot flag difficult or time consuming. It is hitting a checkbox. That's it. One does not need to request the bit if you are giving it to yourself. As for the difference between "real" bots and repetitive edits which don't need to be seen in recent changes et al. -- it is trivial to create a user group with the necessary rights, and call it "flood".  — Mike.lifeguard | ^@en.wb 06:28, 10 August 2008 (UTC)

You don't seem to understand. This proposal is not for a user right. It is for a simple functionality, and it seems that you and a minority of others are making it into a big deal. Essentially, it is a checkbox in one's preferences. Why this is such a source of concern to you baffles me. It'd take 5 minutes, literally, to design and implement. Yes, a bot flag is similar, but my 5 concerns are valid to a degree. So I'm not sure why you are opposed to the idea of making life simpler in this respect, even if a similar function already exists. It's like opposing rollback because undo already exists; sure, undo works fine, but rollback is just better and easier to use. --Anonymous Dissident^Talk 07:37, 10 August 2008 (UTC)

This would be a totally pointless reimplementation of the bot functionality. If you want to do invisible edits, just set up a secondary account with a bot flag. --Tgr 09:06, 10 August 2008 (UTC)

A more useful feature against RC flooding could be to collect edits from the same user with the same summary in a common collapsible group in enhanced recent changes (just as log entries of the same type are collected now). --Tgr 09:09, 10 August 2008 (UTC)

Which is more convenient - flipping a switch, or creating a bot account, making a request, describing its purpose, and then waiting for flagging? You tell me. --Anonymous Dissident^Talk 10:34, 10 August 2008 (UTC)

You are comparing something that only needs to be done once to something that needs to be done regularly. The first time cost for the two methods are having devs implement and test it vs. having every admin needing it set up a secondary account (there are 85 admins on meta, most of whom probably would not need it). The regular cost is logging in as another user vs. changing your preferences, which is roughly the same amount of effort. --Tgr 12:42, 10 August 2008 (UTC)

I have to say that I still don't understand why, and I am afraid this could bring more negative effects than positive ones. We have the situation that every bureaucrat can grant the bot status, and moreover, quite a lot of communities want to discus this first and then make a decision (or consensus). Now, every admin will get the possibility to get by a click something that is very similar to a bot flag (he can make changes first hidden in the RC). If we assume that there are quite many admins who abuse their rights so they will abuse this possibility as well (this is no bad faith, this is reality). But to control this is not that easy and to stop it is quite problematic - in fact I would have to desysop such an admin first. When an admin wants to make serial (and hidden) edits, so he can request for a normal bot flag or for a limited one (by time, by purpose etc.). Once. Zhis is not too much. -jkb- (cs.source) 15:58, 11 August 2008 (UTC)

Logging

I'm having trouble working out from the text of the proposal whether or not the toggling of the flag will be logged (at Special:Log or elsewhere). --bainer (talk) 07:31, 10 August 2008 (UTC)

It's logging will occur in Recent Changes and nowhere else, in the current model. --Anonymous Dissident^Talk 07:38, 10 August 2008 (UTC)

So the intention of the proposal is for there to be no permanent record of the use of the flag (since the recentchanges table is not permanent, but only recent as its name implies)? --bainer (talk) 13:25, 10 August 2008 (UTC)

Choice to follow the flag

Another issue: presently people using recent changes (and watchlists, for that matter) can choose whether or not to utilise the various flags to hide edits (ie. bot flags, anon user flags, minor edit flags). In this proposal, would the flood flag work the same way? That is, would users of recent changes be able to decide whether to utilise the flag or not? --bainer (talk) 07:36, 10 August 2008 (UTC)

Yes. It may be worth discussing whether "flood hidden" edits would be viewed alongside bot edits, or whether "flood" would exist separately from bot edits in Recent Changes. --Anonymous Dissident^Talk 07:39, 10 August 2008 (UTC)

Summary

Okay, we have a rather general agreement that this is a sound idea; some people have asserted that they like the idea, others are luke warm, others don't care, and we only have a few detractors. I think we're fairly clear that it wouldn't be a bad thing to have this done, and there are no visible drawbacks if we have the flipping recorded at RC. I mean, even if one thinks it's pointless or redundant, no-one yet has stated that they think it would actually have a bad side effect. Essentially, if anyone actually thinks that this proposal would be a negative, please state your objection below so that we can be more clear here. Otherwise, I think I'll send in a request to bugzilla in a few days. --Anonymous Dissident^Talk 11:06, 10 August 2008 (UTC)

A bad thing would be an admin like ClownWillEatMe ticking the box, and the RCers missing the admin doing lots and lots of bad things. Instead of a tick box for admins, how about just another parameter at Special:RecentChanges's "Hide minor edits | Show bots | Hide anonymous users | Hide logged-in users | Hide my edits" line: "| Hide admin logged changes"? Patrollers can then see log changes by default, or hide it if they don't. -- Jeandré, 2008-08-10t11:12z

The whole idea of a preference is a bad idea, as mike said, we already have this built into the core software. A preference will...

• Cause more work for the developers
• Take away accountability for the flag, so nobody knows if another user has it on
• Not allow admins to remove it, if someone is abusing it (probably a non-admin)
• Force the flag to be restricted to admins, so that other users who are going to flood, can't hide it

What I proposed does not have those issues and...

• Minimizes confusion between users and bots
• Allows users to remove the flood flag

That way, non admins can have the flag if they ping an admin for it, but they can remove it themselves so that they don't have to ping another admin. The bot flag doesn't allow this, not to mention that it can only be assigned by bureaucrats. Mww113 11:47, 10 August 2008 (UTC)

Okay, as I said above, I'm open to suggestion. How about a tickbox that when switched causes a recorded action in the user rights log? Or a link that is constantly available on the "flooder"'s screen to turn the flag on/off? Regarding the rolling out to non-admins - I'm perfectly happy for this to happen. --Anonymous Dissident^Talk 12:04, 10 August 2008 (UTC)

Jeandré's idea is pretty good and his reasoning too, since enwiki has concerns with admin abuse and "hacked" accounts, this right in the wrong hands can cause havoc, so I disagree with non-admins getting this (well not yet atleast till they find a way to track it easily) and one problem it might have is admins "forgetting" to turn it off so it should have a time mechanism, which will automatically turn the option off if it exceeds a certain time limit (if its possible i.e) ...--Cometstyles 12:18, 10 August 2008 (UTC)

Yes, except it won't allow one to hide the edits of someone flooding RC with edits, so only half the job is done. Also, please, everyone: this proposal is only for Meta as of now. --Anonymous Dissident^Talk 12:25, 10 August 2008 (UTC)

Yep I know its for Meta only, but if we can improve it for all wikis and then test it on Meta, pretty soon other wikis can have it too without much debilitation..--Cometstyles 12:47, 10 August 2008 (UTC)

IMHO the proposal is typical feature creep - reimplementing bot flags with a slightly different behavior would use up developement resources and make the source code more complex for little to no benefit; there is almost nothing in this proposal that could not be currently done some other way (see my first comment on this page). (Also, it is not clear whether this is only for meta or a per-wiki opt-in thing -- in the first case it makes even less sense to change the core because of it, and in the second, you should probably check first how many wikis actually want this.) --Tgr 12:30, 10 August 2008 (UTC)

There is also a security problem - if someone hacks an admin account (or hacks the community to make him an admin :), he can do changes to the javascript in bot mode, which is Very Bad. While this might not be much of a problem on meta, which is rarely targeted by attackers, I certainly would object such a feature (or anything else that gives bot flag and system message editing ability to the same account) on my home wiki. --Tgr 12:53, 10 August 2008 (UTC)

Problems - why don't we review the original design

We seem to be going around in circles here. The main advantage of this is a simple way to filter out masses of edits. In the beginning, I envisaged a switch, a simple tickbox; this was apparently no good. I envisaged that its flipping would not be recorded in a user rights log, but apparently this was no good and since preference changes cannot currently be recorded in the logs the idea of having the switch in the preferences was no good either. The original idea of a tickbox was fine and easy, but issues of trust and such, issues which are actually quite imaginary on Meta (we haven't had an admin go rogue yet, and even admin errors are rare), tainted this to the point where it has become something of a bot duplicate. I really fail to see the issue with having a simple tickable box in the preferences that would filter edits from the mainmstream RC, but could be viewed by opt-in as bot edits are. Simple. In fact, much simpler than assigning and taking away bot status every time. This is a utility, at the end of the day. It makes things simpler, anbd nothing is simpler than ticking a box. This is a minor matter, and one should not need to go about adding and revoking a user class every time one wants to flood RC. --Anonymous Dissident^Talk 12:44, 10 August 2008 (UTC)

1. It needs to be logged: done
2. It needs to hide edits from RC et al., but allow the edits to be visible upon request: done
3. It needs to not require a bureaucratic process; users should be able to turn it on and off themselves: done

I don't understand why you want to reinvent the wheel. This is exactly what the bot permission, $wgAddGroupsToSelf and $wgRemoveGroupsFromSelf are for. I repeat: This is exactly what they are for. Clogging development with trivial coding requests while near-identical (I would say superior) functionality is available in core software already is a bad idea. We have the ability to do this already without coding changes - let's do it.  — Mike.lifeguard | ^@en.wb 14:00, 10 August 2008 (UTC)

I want to "reinvent the wheel" because I believe that the "wheel" is laggy. I believe this flood flag is a more convenient and smooth utility than a user-right that exists for automatons. But, alas, I don't wish to argue. Disagreement sometimes is inevitable, and I respect your view on the matter. It would be silly to get into a conflict over something so minor, something that's currently only a proposal, but a conflict is evidently where it's headed judging by the capitalisation of your edit summary. So, I won't say any more on the matter. Your opinion is that we should use pre-existing functions; mine is that we should simply improve the ease of use for this function for non-automatons wanting to hide their edits periodically, rather than all the time. That's all there is to it. Cheers, --Anonymous Dissident^Talk 14:23, 10 August 2008 (UTC)

I'm not upset, you simply seemed to not be getting the message. There are not problems that I can discern with using existing functions which would suggest that coding is needed. If that's the case, we do not need a solution for that (essentially nonexistent) problem.

Since there is general agreement to move this forward, can we have a straw poll on enabling this as follows:

$wgGroupPermissions['flood']['bot']             = true; #creates the "flood" group with the "bot" right
$wgGroupsAddToSelf['sysop'] = array('flood');           #sysops may add the "flood" group to themselves
$wgGroupsRemoveFromSelf['sysop'] = array('flood');      #sysops may remove the "flood" group from themselves
$wgRemoveGroups['bureaucrat'] = array(
 'flood',                                               # only this line is new; it lets bureaucrats remove the "flood" group from users
 'ipblock-exempt',
 'bot',
 'sysop',
 'bureaucrat');

If there is support for using this method, we should then discuss some guidelines for use:

1. When should one use a bot account, versus flagging oneself?
2. How do we deal with abuse of this function?
3. Other issues I haven't thought of.

I have some thoughts on these questions, but we should have a quick gauge of support before proceeding, I think.  — Mike.lifeguard | ^@en.wb 14:30, 10 August 2008 (UTC)

Listen, essentially, I am happy to use the pre-existing MW format. I don't care. It just seemed as though my idea wasn't being understood, to cut a long story short, and, being tenacious, I felt a need to make sure I was expressing it properly. Forget it. To the first: I think a bot account should be utilised when one plans to make a load of edits that are less than fully automated, whilst one should flag oneself for a load of repetitive edits that are to be made manually. Secondly: I think that abuse of the function would result basically in revoking of the ability to "bot" oneself, and further to this, it seems likely that secretively making abusive edits would leave somebody's entire sysopship in question at any rate. Thirdly: we need to think of a name for this user class (at least, I think that is what you are proposing: a new user class identical to bot but named differently to prevent confusion? If this is not the case and you were thinking that we'd simply stick with the "bot" name, then I support that too. Do note it is incredibly simple to duplicate user groups in MW, especially if a name is merely being altered, so developer time isn't an issue there to the best of my knowledge). Finally, I think a whole new superheader should be placed for the straw poll, if not a subpage. --Anonymous Dissident^Talk 14:45, 10 August 2008 (UTC)

OK, thanks for the clarification. I did understand your proposal perfectly - that's why I took issue with it. For those who wouldn't know, the settings I gave (requiring trivial effort from a sysadmin) create a user group called "flood", which admins may grant to and remove from themselves only. This "flood" group has the bot right, which is what hides things in recentchanges. I do agree with the rest you've said. I raised the issue of abuse, rare though it may be, because we cannot remove the ability to flag oneself. I don't see this as an issue precisely because I would want a user's sysop bit removed if they are abusing this (just like I would want it removed for abuse of any other admin tool).  — Mike.lifeguard | ^@en.wb 14:57, 10 August 2008 (UTC)

$wgGroupsAddToSelf and $wgGroupsRemoveFromSelf will not work for this purpose. They are designed to let everyone add or remove groups from themselves, there is no way to only allow specific groups to use this. As such, if you decide to implement it this way, it will allow every user to add or remove 'admin' and 'flood' groups for themselves, certainly not what was planned. I've previously talked with brion about changing the functionality of these two variables to work more like $wgAddGroups and $wgRemoveGroups (where it is a multi-layered array with 'group name' => array(groups), which would work then, as you could have $wgGroupsAddToSelf['admin'] => array('flood')), but he previously opposed that change in core. Until such a change gets implemented, it may be best to pursue some other alternative. --Skizzerz (talk) 15:19, 11 August 2008 (UTC)

Expletive deleted - I have seriously misunderstood these settings then. Then we shall need coding done to support this :( I'll submit a bug shortly.

An alternative then would be to allow admins to grant this to anyone. I don't really like that idea.  — Mike.lifeguard | ^@en.wb 17:09, 11 August 2008 (UTC)

Skizzerz has coded this for us (assuming Brion doesn't want changes made)! :D  — Mike.lifeguard | ^@en.wb 22:36, 14 August 2008 (UTC)

Straw poll

1.  Support  — Mike.lifeguard | ^@en.wb 21:36, 11 August 2008 (UTC)
2.  Support Good idea --Mardetanha ^talk 14:40, 10 August 2008 (UTC)
3.  Support Sure. Cbrown1023 talk 14:44, 10 August 2008 (UTC)
4.  Support see my recent comments above. --Anonymous Dissident^Talk 14:46, 10 August 2008 (UTC)
5.  Support the idea, specially in the way Mike mentioned it.Huji 21:30, 10 August 2008 (UTC)
6.  Support, if the coding necessary is done. --EivindJ 18:32, 11 August 2008 (UTC)

   #(+) The solution $wgGroupsAddToSelf = array('admin', 'flood'); is simple and effective. Hillgentleman 02:23, 11 August 2008 (UTC) All right it doesn't work. Perhaps we may go back to the old "every sysop can automatically become a bureaucrat as in the spanish wikipedia" idea. Hillgentleman 18:28, 11 August 2008 (UTC)

7.  Support intent, oppose current method of reaching it. See my comment above. --Skizzerz (talk) 15:19, 11 August 2008 (UTC)

   Well, would you support what was intended (it will then require coding to be implemented though)?  — Mike.lifeguard | ^@en.wb 17:09, 11 August 2008 (UTC)

   Yes, I support the intent. Changed my vote to match that. And yes, it will require some sort of coding to implement it... I'll see if I can talk brion into changing how $wgGroupsAddToSelf and $wgGroupsRemoveFromSelf work again, since I still have the patch for it (albeit for an earlier mw version) lying around somewhere on my comp. --Skizzerz (talk) 19:33, 12 August 2008 (UTC)

8.  Support This would help RC patrollers everywhere. LegoK^ontribsT^alkM 16:39, 12 August 2008 (UTC)
9.  Support OhanaUnited^{Talk page} 17:54, 12 August 2008 (UTC)
10.  Support per Skizzerz. —Giggy 02:31, 13 August 2008 (UTC)

     Oppose- strong oppose unless there is an option in preferences to view flood. Keep it open. Emesee 02:05, 16 August 2008 (UTC)

    User misunderstood the proposal, AnonDiss explained it better below. Cbrown1023 talk 13:05, 16 August 2008 (UTC)

     Oppose - Still oppose unless that is explained more explicitly in the first paragraph and somewhere else, what sort of edits one might want to flag as flood. Emesee 19:55, 16 August 2008 (UTC)

    The intent seems reasonable clear if one reads the proposal and/or discussion. I have added examples on the proposal page though.  — Mike.lifeguard | ^@en.wb 20:35, 16 August 2008 (UTC)

11.  Support Good idea. This has to spread to other wikis. Admiral Norton 18:53, 16 August 2008 (UTC)
12.  Support Provisional support - Unless the community will be fully aware about the flood flag on implemention i oppose it. There should be a button in BIG text saying view Repitious edits or something. Prom3th3an 11:00, 23 August 2008 (UTC)

    I doubt very much there'll be a big notice drawing attention to this, where its whole purpose is to remove stuff that would otherwise flood RC and captivate our attention. —Giggy 11:42, 23 August 2008 (UTC)

13.  Support Might prove useful and bring some relief to RC. Can't think of any negative implications. Húsönd 01:58, 29 August 2008 (UTC)

Alternative idea (I think)

What about handling this in a different way (if technically possible): (1) The admin could tick a box tagging the subsequent edits as minor admin edits; and (2) the display of recent changes would have as a default to not display those edits, unless a user ticks a box to show all edits (the minor admin ones included). Sorry if this has already been discussed elsewhere, but it would seem to meet all needs. --A12n 12:59, 10 August 2008 (UTC)

Minor edits have a different meaning; you can already hide those in recentchanges. I would not support having minor edits for all users (or even for admins only) hidden by default in recentchanges.  — Mike.lifeguard | ^@en.wb 14:31, 10 August 2008 (UTC)

Yes, do not confuse minor and flood. But really, this «flood» should not be an user's flag, but an edit's. In any case we may not label all edits of some person as hidden, or bot-like. Only those edits, which the author itself consider (on his reputation's risk) as flood. Switching flood-flag on and off on the same account can be dangerous; there is a risk to proceed (by mistake) to non-flood task with flood flag set on. Why not just to register some sysoped bots for such administrative tasks? Incnis Mrsi 17:22, 23 August 2008 (UTC)

The whole point is that the designation of "flood" is transient (just like "bot") - there is no need for a persistent flag on the edit - we care only about the entry in recentchanges. For admins accidentally leaving the flood flag on, any 'crat may remove it.  — Mike.lifeguard | ^@en.wb 22:33, 23 August 2008 (UTC)

Problem to really solve is approached from the bad direction

The human goal is perfect, however the technical approach is from the bad direction.

The bad idea is the tampering of the real history, regardless whether this tampering can be made by the abuser himself/herself or anybody else.

In addition to this, never mix the notion of trustability and trackability, it is always an essential design error.

• feed the database with the raw truth, what really happened

• query the databese as you wish, filter the information how you feel comfortable

Hence the general flood problem (not only the special case mentioned in this proposal page), should be handled by filtering on the query pages, like Special:RecentChanges in question, or Special:Contributions similar to what is in question, or consider even the Special:WhatLinksHere pages.

In fact, yesterday I wanted to collect the pages I ever touched or where my contribution is more than 1024 bytes. To this end I visited my contributions (naturally on my native language), and I was flooded with the detailed information whatever I did.

Whatever kind of history page I examine, there are a few click-controls, how to filter the history, or you know that you have some filtering facility in case of Toolbox / What links here as well.

In addition to this, nice (top) mark can be seen in my personal history at each entry, which corresponds to the last editing of that particular page/article...

Why you do not suggest the following two obvious and trivial features, extending the filtering facilities on the diverse listings, namely:

• wherever the (top) mark is is already implemented in a type of listing, then there should be an ON/OFF button to restrict the listing to the items containing the mark in question

• a natural solution to your particular problem can be done by rasterizing with respect to time. An actual user interface to this solution could offer the selection of the period of the time raster, and the selection whether to collapse within a raster concerning the editors or concerning the pages. Then, within each period of the time raster, the traffic of each page is accumulated into an entry, the time location of that entry in the period in question is the time stamp of the last activity. When you click on such an accumulated line, then you will arrive to the appropriate section of the page history of the page in question. If your selection was to collapse with respect to editors, then the activity of each editor is accumulated separately and positioned in the listing according the time stamp of the last activity within the time period. And this case, clicking on the collapsed summary line of an editor in a particular time period will bring you to the appropriate section of the editor's activity history.

• it is a security issue, not to make any distinction between admins and non-admins, when we investigate the diverse hitories, the log information. Even the most reliable person can have a bad day. Probably you have already observed, that sometimes the greatest disaster to your own, personally maintained computer is you yourself (just a sudden extraneous space in your system administrator command can be enough for a disaster).

Let us mention here, that the filter Hide minor edits makes no too much sense, since the This is a minor edit mark is voluntary. If you want to make a real patrol contribution, then better not to rely on it. Actually I would remove this facility from the whole system. To remove a stub marker is a minor edit from the reader's point of view, but it is a major edit from the admin's point of view, and the difference in bytes is 8 characters plus a newline only.

Conclusion: the history filtering facilities must be reconsidered and rediscussed carefully. That will solve your problem proposed here, and also many other problems not addressed with the original proposal here.

Prohlep 15:52, 10 August 2008 (UTC)

Turn off "hide bot edits" in RC, then you can see flooded edits. The filtering mechanism in RC already supports your change. It's honestly easier to simply request that the sysadmins add a bot-like group that admins can turn on and off for only one wiki rather than ask for both a new core group (which duplicates the functionality of the 'bot' group) and a new toggle for RC. Please feel free to write up a proposal for your revamping of the RC system and new permissions groups, then alert someone familiar with bugzilla so they can pass your proposal on to our software developers. If you already have an extension in mind that would drastically improve things, please say so. Kylu 17:04, 10 August 2008 (UTC)

Ability

It states on the main page that Administrator's will be able to prevent edits from being seen or monitored - however doesn't this closely resemble the Oversights, they have the ability to hide revisions and edits. Dark Mage 17:23, 10 August 2008 (UTC)

No, the edits are shown in edit histories, Special:Contributions etc as normal. The only difference is that (like bots) they are not shown by default in Special:Recentchanges. You can view them by clicking Show Bots.  — Mike.lifeguard | ^@en.wb 17:29, 10 August 2008 (UTC)

Ok thanks, I wasn't sure. Dark Mage 17:30, 10 August 2008 (UTC)

Autopatrol

How frequently sysops request a temporary bot status, now? In the italian projects, AFAIK, we can simply hide sysops' edits because they can autopatrol them. --Nemo 19:02, 10 August 2008 (UTC)

This is different from hiding patrolled edits. Patrolled edits are not hidden by default, and are shown in recentchanges by default.  — Mike.lifeguard | ^@en.wb 19:19, 10 August 2008 (UTC)

I can't remember such a case in dewp ever. So the first question should be here: Is there any need? --DaB. 01:44, 12 August 2008 (UTC)

Not on dewiki then. But it seems there is some rough agreement that this is desired on meta. Unfortunately, I have rather derailed this with a technical misunderstanding.  — Mike.lifeguard | ^@en.wb 02:13, 12 August 2008 (UTC)

Opt in/out

I cannot find it, therefore a question: is there - or will there be - a posibility for projects not to take part in this extension? -jkb- (cs.source) 23:12, 12 August 2008 (UTC)

It is not an extension. It would be a configuration setting, which would be requested on a per-wiki basis. This proposal is for Meta only.  — Mike.lifeguard | ^@en.wb 00:47, 13 August 2008 (UTC)

Don't mind please my extravagant technical knowledges :-). Thanks for answer. -jkb- (cs.source) 07:55, 13 August 2008 (UTC)

To bugzilla?

See the poll above. To Bugzilla? —Anonymous Dissident^Talk 10:24, 15 August 2008 (UTC)

Since Skizzerz has done the necessary coding and we don't have any outstanding objections to what was voted on, I think we can go for it. —Giggy 11:01, 15 August 2008 (UTC)

Do we have a few 'crats supporting? I'd like that to happen before we proceed.  — Mike.lifeguard | ^@en.wb 13:40, 15 August 2008 (UTC)

I guess I don't have any qualms if you'd like to wait. I'm just not sure if we can extend our exposure much more; I think most people who are going to see this have. —Anonymous Dissident^Talk 15:25, 15 August 2008 (UTC)

Yeah, I had forgotten there was something in the sitenotice. Since that's the case, I'm fine to do the request now.  — Mike.lifeguard | ^@en.wb 15:43, 15 August 2008 (UTC)

bugzilla:15176  — Mike.lifeguard | ^@en.wb 15:53, 15 August 2008 (UTC)

Thanks much Mike. —Anonymous Dissident^Talk 00:03, 16 August 2008 (UTC)