limit number of tasks per challenge to 10,000

[mvexel]

Large challenges can slow down the system. There's also a UX reason -- limiting the number of tasks forces the challenge creator to think more carefully about what they ask the community to fix and break up the challenge in smaller questions or regions.

[nrotstan]

It also needs to be discussed whether -- as part of this change -- we would also automatically split up existing challenges that exceed whatever cap we decide upon. On impact is that it would mean people currently using the API to manage some aspects of their challenges may need to update their scripts to account for additional challenge ids.

[1ec5]

The Silicon Valley POI import currently hosts about 23,000 tasks spread across 59 challenges according to how the source data was organized. The biggest challenge has 7,000 tasks, which may increase slightly over the next few months. Splitting apart challenges would make it more difficult to comply with the limit in #1536 on the number of challenges. Taken together, the import would have to be split into multiple projects, making it impractical to rely on MapRoulette for this import.

Large challenges can slow down the system.

Since November when we set up the Silicon Valley POI import challenge, I haven’t really seen any performance issues that affect the usability of the project, except that overall project statistics have begun timing out over the past couple days. If the performance issues are specific to the statistics, would it be possible to load statistics only on demand or provide less detailed statistics for large projects? Or is the project causing backend performance issues that aren’t visible to users and project administrators?

[Noki]

@mvexel @nrotstan The maintenance of my challenges is already a nightmare because of overpass API timeouts and the large number of challenges required to bypass those issues. A task limit or challenge limit within a project would make it even more difficult and I would most likely not be able to to update tasks in under 30 days and even within 7 days in some countries as requested by some users. In addition I currently don't have much time to rewrite all my code and I'm afraid that won't change anytime soon. Going forward with the proposed changes would probably mean that someone else needs to take over the phone number challenges and maintain them (fine for me if someone is interested, but expect to answer quite some mails from users as well) or the will stop to exist.

I proposed automated global challenges in the past to deal with these issues and still hope that you add something like that.

In terms of performance and UX you should just limit the number of tasks you show instead of limiting the creation. You should use pagination and/or hard limits within the UI whenever possible (e.g. to list challenges) to speed things up. You should also have background jobs to transform data into something that is always fast when accessing it. Finished tasks could probably also be deleted after a some time, however this would require to persist the user-points for the leaderboards.

[jschwarz2030]

Per @mvexel, we are raising priority on this issue. I will implement a variable task cap to challenges in order to prevent server instability. This will be considered a temporary solution, as the points above are valid; the Maproulette queries have room for improvement. We will identity these as we continuously improve the system.

[mvexel]

Some feedback indicated 10k may be a little low. I would be okay with 50k. For use cases that require more tasks per challenge, there is the option of a self-hosted maproulette, in case we make it configurable.