-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better deduplication of new puzzles #2275
Comments
Wanting to prevent this failure mode (more often) is reasonable; I wouldn't be opposed to warning when we detect a dupe URL or title. Did you find that these were usually people racing to add the same puzzle at around the same time (right as it unlocks), or more failure to notice the puzzle was already entered at some later time? FWIW, we've usually (mostly) solved the former problem in the past by having a single person responsible for puzzle entry at any particular time during the hunt. I could also imagine an orthogonal approach to this problem shaped like having basically a stealable lock that can be held by at most one person at any particular time, and which you have to steal before you can fill out the add new puzzle form (and if it gets stolen out from under you then you'd see that happening). Then at least people can notice that they're all trying to do the same thing. The latter approach might also help deal with the fact that since the Google interactions can sometimes add some seconds of latency to puzzle creation, it's entirely possible that even with perfect dupe detection/warning in the form, we might still wind up with multiple requests in flight to create the same new puzzle from different puzzle-adders at the same time. So the "teamwide lock" idea appeals somewhat because it helps prevent that situation, but then it also means only one person can be keying in new puzzles at a time, which might add unwanted friction. Thoughts? |
This was typically due to multiple people racing when new unlocks happened. For MITMH, with our large team size, we do typically have a rotation of on-duty puzzle admins, so it's not as much of a problem there. Enshrining that with a formal "lock" would be a nice enhancement though we've managed okay without it in the past. I don't think that approach works as well for smaller hunts like this, though. We had a team of 5 people solving at different hours / in different capacities, so its harder to coordinate any sort of extended shift as a puzzle admin. (Also, with the sheer number of puzzles on this particular hunt, it would have been pretty miserable being responsible for adding them all). A little warning would be helpful there. |
When multiple people on a team are permitted to add puzzles, it's all to common to accidentally add two entries for the same puzzle, which creates confusion.
I don't know that it'd be safe to require uniqueness of URL. I could imagine wanting to create multiple entries for a puzzle that's all present under one URL (It's definitely not safe to require uniqueness of title, as we've learned from GPH over the weekend...). But it feels to me like we could do more for the more common case that two entries represent the same puzzle rather than use the same URL but are intentionally distinct.
My initial thought is to detect duplicates by URL (or title?) and show a warning if there is one with a link to the other entry. From there, the user could opt to bypass the warning and add the new entry if the duplicate is expected. I think that would help a lot in preventing unintended duplicates without interfering heavily with regular workflows.
The text was updated successfully, but these errors were encountered: