Last modified: 2012-03-26 18:06:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T37374, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 35374 - Feedback Dashboard rate limiting too severe
Feedback Dashboard rate limiting too severe
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
unspecified
All All
: Normal minor (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-21 06:20 UTC by Richard Ames
Modified: 2012-03-26 18:06 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Richard Ames 2012-03-21 06:20:00 UTC
In version 1.19wmf1 (r114160) the response rate limiting is too drastic.  When a user is happy and has never made an edit the responses can be pasted in quickly. Rate limiting interferes with this.

Can we maybe have 'trusted' users????

Thanks, Richard.
Comment 1 Mark A. Hershberger 2012-03-22 17:04:13 UTC
(In reply to comment #0)
> In version 1.19wmf1 (r114160) the response rate limiting is too drastic.  When
> a user is happy and has never made an edit the responses can be pasted in
> quickly.

I don't understand why this should be allowed.
Comment 2 Richard Ames 2012-03-22 22:17:40 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > In version 1.19wmf1 (r114160) the response rate limiting is too drastic.  When
> > a user is happy and has never made an edit the responses can be pasted in
> > quickly.
> 
> I don't understand why this should be allowed.

So the 'Responders' can be more efficient and not waste their time waiting for the rate limiting clock to expire....
Comment 3 Erik Moeller 2012-03-22 22:29:59 UTC
Adding Benny, who can help find a good solution here.
Comment 4 bsitu 2012-03-22 22:54:16 UTC
We can adjust rate limiting time based on user's edit count and registration date.  users are more trusted if they have higher edit count, especially response to feedback also contributes to edit count.
Comment 5 bsitu 2012-03-22 23:01:40 UTC
(In reply to comment #4)
> We can adjust rate limiting time based on user's edit count and registration
> date.  users are more trusted if they have higher edit count, especially
> response to feedback also contributes to edit count.

To be safer, we can also look at the user's number of response in the last minute, if the number looks like a spam, we can automatically block the user.
Comment 6 Erik Moeller 2012-03-22 23:07:57 UTC
Benny, there's a user group called "autoconfirmed" which is a simple activity/duration threshold that we can check for. See
http://www.mediawiki.org/wiki/Manual:User_rights

I don't know what the rate limits are right now, but if we just want to make a small change to accommodate fast humans, the autoconfirmed threshold may be a sufficient check (user account is 4 days old and has made at least 10 edits).
Comment 7 bsitu 2012-03-22 23:29:34 UTC
(In reply to comment #6)
> Benny, there's a user group called "autoconfirmed" which is a simple
> activity/duration threshold that we can check for. See
> http://www.mediawiki.org/wiki/Manual:User_rights
> 
> I don't know what the rate limits are right now, but if we just want to make a
> small change to accommodate fast humans, the autoconfirmed threshold may be a
> sufficient check (user account is 4 days old and has made at least 10 edits).

The rate limit for response is 60 seconds, we can adjust this for autoconfirmed responders.  It seems to me that it's quite easy to get the "autoconfirmed" permission, I was thinking about even higher criteria.
Comment 8 Richard Ames 2012-03-23 00:06:38 UTC
(In reply to comment #7)
 
> The rate limit for response is 60 seconds, we can adjust this for autoconfirmed
> responders.  It seems to me that it's quite easy to get the "autoconfirmed"
> permission, I was thinking about even higher criteria.

I would agree 'autoconfirmed' is too easy to get for this use ....  you need some experience to answer the feedbacks, etc.

I suggest:

rate limit = 120  ----- raise as needed to stop abuse.

If autoconfirmed then rate limit = 60

If edits > 2500 then rate limit = 10

Thanks and Regards, Richard.
Comment 9 Erik Moeller 2012-03-23 00:11:43 UTC
The original motivation for this rate limit was to prevent flooding. I'd say let's do what's necessary to meet that objective. If there are other objectives (e.g. incentivizing good responses), it's not clear to me that rate limits are the best tool to do that.

So I'd be in favor of reducing the rate limit to something barely noticeable for autoconfirmed users (~10 secs) and seeing if we still observe any issues with flooding.
Comment 10 bsitu 2012-03-23 17:20:01 UTC
I will add this to moodbar while I am learning to use gerrit and git today, :)

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links