Could a workaround for upcoming mapathons be to let the participants just map the buildings as nodes (possibly adding diameter=* for circular buildings)? While it won’t show up as nicely on most maps, it would be enough to allow workers on the ground to find where there are buildings. It would also be easy to as a next step do a search for these buildings (mapped just as a node and in a changeset with some hashtag as you presumably already use), allowing (humanitarian) mappers with enough edits to not be hit by rate-limits to make them into areas (this is of course not an ideal solution, so should just be seen as a workaround).
I just had a look at How about limit new accounts? (only followed it very shallowly previously) and interestingly I got no search results for either “missing maps”, “mapathon”, “hot” or “humanitarian”. Unless your use case was mentioned somewhere else in the discussion (or I just didn’t use the right search terms) it seems like this use case (mapathons for new mappers) wasn’t considered. If this is the case I think you (the humanitarian mapping organizations) should consider that missing out on a discussion that affects your work so gravely is a pretty big red warning sign that you have some work to do on your cooperation with the larger OSM community. As a community, we of course want to consider everyone’s thoughts, but you can’t count on someone else bringing your thoughts to the table. How frequent are members/representatives of the humanitarian organizations on this forum?
I think three issues are being discussed here, and that it would make sense to try to separate them:
- Finding a work-around that allows working with the existing rate limits
- Finding another rate-limit or alternative (procedure/organizational)
- Implementing another rate limit or alternative (technical)
I feel like 1. is ultimately up to you (the humanitarian mapping organizations) to solve, but you’ve received some good tips here already.
Provided that some consensus can be reached on 2., is there someone from “the humanitarian side” who could implement it in openstreetmap-website (for example someone working on the HOT Tasking Manager)? Alternatively, would there be funding available to find someone else (possibly one of the ordinary maintainers) to implement it? If no to both these questions I think you’ll have to be prepared for a solution to take time to be implemented (unless one of the ordinary maintainers feels like this is a priority, but as volunteers that would be completely up to them of course). Likewise, I think any requests to increase the overall rate limit (or other solutions that would risk letting more bad faith edits in again) should be accompanied by an offer from someone to volunteer to join the DWG to help them handle the possible increase in vandalism.
I think all the suggestions for 2. that have been brought forward so far have some merit, though I think we should be careful about solutions that are along the lines of “just handle mapathon participants separately”; both because it might risk weakening the “no one is more important/has more decision power than anyone else”-aspect and because it might risk increasing the workload of the DWG (if they have to manually handle these exceptions).
I’ll throw a variant of the suggestion by @DavidKarlas (and similar by others) into the ring:
Taking some inspiration from the StackExchange point system (hey, maybe we should have something similar in more ways than this?); any mapper can “vouch” for other users. Vouches remove (or increase) the rate limit of the users vouched for during some specified time period (normally the duration of the mapathon). A mapper can only “vouch” for N users at a time, where N is based on their changeset count/years of experience/something else (since, usually, a more experienced mapper should be able to help more newcomers at once). The power to vouch for another user can be taken away (for example if the DWG finds a lot of bad edits from users vouched for by some user, or even reasons to ban users vouched for). A possible extension could be that “vouches” are only valid for changesets with some specific hashtag or within a specific area, and that they might require a link to the wiki page for the mapathon in question.
My understanding of the guidelines (Organised Editing Guidelines - OpenStreetMap Foundation) is that you should have one page per activity (for one-of activities like mapathons I would count each mapathon as a separate activity). It might be a bit outdated, but there is even a sample page on the wiki: Organised Editing/Activities/Trains of Botswana mapathon - OpenStreetMap Wiki
I think following the OEG and writing proper documentation on the wiki should be a base requirement before any kind of rate limit exemptions can be implemented.
As there are somewhat frequent complaints about the data quality it might also make sense to update each activity page once post-event validation/cleanup has been done, noting who was responsible for it and what was done (which QA tools where used etc.).