[openstreetmap/openstreetmap-website] Limit number of edits per user and day (#2342)

Andy Allan notifications at github.com
Wed Dec 11 16:38:30 UTC 2019

> Approval queues have been suggested by a number of people in the past. I believe the concept would be extremely expensive to implement, it would cause massive disruption all over, hence it is simply not feasible. Besides, there's noone to review changes in time, and then those queued changed become stale and conflict with other changes that have been done in the meantime. Good luck resolving those.

I completely disagree about review queues for changesets. We already have a need for send-and-poll for changeset uploads, [as I've described in a blog post](https://blog.gravitystorm.co.uk/2019/10/17/smoother-api-upgrades-for-openstreetmap/) and discussed with various editor developers. If that was implemented, then there is an opportunity for changesets to be reviewed before being applied. I would intend for that to be default-approve, immediately at first, and then with longer windows (e.g. 1 minute) as we develop processes and capacity to handle them. We could have longer timeouts based on changeset size, user status, all kinds of things.

But unfortunately this is all pie in the sky while we have so little development capacity available. So let's label this as "future" and return to more achievable goals.

We could do with having some default limits for all kinds of things - number of diary entries per day, number of gpx uploads, number of notes closed per day, number of changesets per day. It's not sustainable having all of these as "completely unlimited". We should add some safety rails.

This isn't a new concept, we already have it for messages per hour, for example.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20191211/56941038/attachment.html>

More information about the rails-dev mailing list