limit number of challenges per project to 100

[mvexel]

related to #1535 To prevent huge projects from slowing down the system, and to make creators™ think more about organizing their work.

[nrotstan]

It also needs to be discussed whether -- as part of this change -- we would also automatically split up existing projects 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 projects (or child challenges) may need to update their scripts to account for additional project ids.

[mvexel]

I do think we need to align existing Projects and Challenges with the new caps. However, this would need to be communicated really well to ensure owners are not taken by surprise. I can see a path where we implement #1543 first so we have a clear and consistent way to contact owners, then proceeding with enforcing the new cap on existing Projects and Challenges.

[1ec5]

The Silicon Valley POI import currently hosts 59 challenges, divided by editor preset. Combining challenges further would make it difficult to communicate tagging instructions to mappers and increase the likelihood of poorly mapped tasks. It would also make it much more difficult to comply with the task limit in #1535 – our biggest challenge has about 7,000 tasks due to how the source data was organized.

[nrotstan]

While that's large, I don't think it's unreasonably large. We're probably looking to cap projects at ~100 challenges and challenges at ~10,000 tasks, depending on the feedback we receive. We're mostly trying to avoid the challenges with 80,000 tasks in them or the projects with 1800 challenges. At those extreme sizes, chances are good that there's scope to break things apart in an organized fashion.

[1ec5]

Thank you for clarifying the intended limits. Those limits would comfortably accommodate a project like the Silicon Valley POI import and similar projects at a county level. I agree that something an order of magnitude larger is likely to be more manageable if broken down by geography. My local community is considering importing some very large datasets later on, but a challenge as large as 10,000 tasks would probably be more efficient as a non-microtasked bulk import anyways.