In our university, we arrange individual contest on regular basis. So, I really think we can actually use this huge archive of problemset of toph. But as the solution of these problems are public and we can easily find the problem from archive section just by searching it’s name, its not easy to arrange a contest with this problem set.
But it can be easily done if we can change the name of a particular problem (Or little bit from the statement) from archive while synching with a contest.
I like this idea a lot. Let me actually think about it a bit, about how we can best implement it. Thank you for suggesting this!
Nice idea. From the perspective of a setter of practice/team forming contests, it will make life much easier 
Adding on, I think this is similar to what VJudge provides. When you add a problem to a contest, you can edit its name and any part of statement for that specific contest only.
@Zeronfinity I agree. And, if we limit this to just the title and statement this should be a fairly quick implementation. This will of course be available for problems that are added from the archive (not from Toph Drafts) to make sure that until the problem is published to the archive, there is only one source of truth for the problem statement.
On a side note, organizers now have the option of creating password-protected contests.
@hjr265 Wouldn’t it be nice if Toph have a system like: those who are participating in the contest can not see the submissions of the contest problems?
In this system if the contest have any archived problems, the user shouldn’t be able to see those problems submissions.
And please brief about this 
@mdvirus, what if the user uses another account to see the submissions?
I am thinking of a little tweaked version of this, though still not sure how feasible it will be.
Whenever a contest is ongoing, training or not, submissions of the archive problems used in the contests will become automatically locked i.e. if anyone wants to see the solution of a problem currently in a contest, he/she won’t be able to. They will also become automatically unlocked after the contest ends.
Since at a time there aren’t that many contests using archive problems, it should not be a problem.
This feature would help out a lot in organizing the kinds of contests this post in concerned about, making organizers worry less about cheating.
At first, something like this had crossed my mind too. It really would be a good solution.
But i didn’t say anything about it because i thought it might affect other contestant if they were up-solving from archive at that moment. But now if you think about it, the probability of a problem getting locked because of it is being used in a contest isn’t that high.
Toph has over 1000+ problems in their archive. So probability of getting a problem locked isn’t that high for a single contest . So, this suggestion will be really good if the contest duration is <= 5hour. But what will happen if anyone starts a 5-10 days marathon contest with that problem and it gets locked for that long period? :3
I guess there can be a threshold on the duration. 5-6 hours sounds reasonable.
I think there is some solution:
A problem won’t be locked if it is synced in a contest where the duration is more than 5 hours. Because whether it is a team practice contest or individual practice contest, the duration of a contest doesn’t exceed 5 hours usually.
If a problem is used in a contest and locked. No one for the next 24 hours after the contest won’t be able to sync that particular problem to any practice contest. (It will be helpful for those who wants to upsolve it after that contest)
I think we can do something simpler:
Generated accounts cannot see source code of submissions other than their own.
There is an existing functionality of black/white listing IP addresses for a contest. People cannot enter a contest from black listed IP addresses, and they must enter the contest from one of the white listed IP addresses. In case a contest has one or more IP addresses white listed, and the contest is running, people coming in from those IP addresses cannot see source code of submissions other than their own.
A plagiarism checker is being implemented. And, policies will be introduced to make sure plagiarism is punished. Attempts to steal other’s work on Toph during contests will have strong and often permanent impact on their account.
1 and 2 should be sufficient for a majority of on-site contests. The only exception would be on-site contests using personal accounts and the contest environment not having known IP addresses (unlikely). That is where 3 would play a role.
One advantage here is that during these contests Toph’s features are not affected for the rest of the community.
For events where absolute invigilation is required, I can always disable source code view entirely for the duration of the contest.
For off-site contests, it is a different story altogether.
I think these won’t be sufficient, from the point of view who sets such contests for juniors.
Our team forming depends on such contests, so we try to make sure there is no way to see a solution and use that information to gain an unfair advantage. Thus, while setting such contests, we assume that someone will try to cheat, even if there is no person who’d do such a thing.
Let me now explain how your points fits in our situation.
Generated accounts is not possible for us since we have no feedback on exactly who/how many will participate in our TF contests. We try to keep the participation less complex so that someone new who wants to join doesn’t feel overwhelmed and can simply join if he/she wants too. There is also the matter of preparation time. We often need to take TF contests on short notice due to emergencies.
For the same reasons as above, and also because there might network issues in campus, we allow our contestants to use their own mobile network for the contest. Thus we can not make use of this feature as well.
This will be great. But a good contestant doesn’t need to copy paste code, he can just see the solution to get the general idea or some clues and code it from scratch on his own. One can say that good contestants are usually morally good or don’t need to cheat anyway, but we try to work assuming worst-case scenario even if it’s highly unlikely.
But suppose we are taking 3h or 5h contest with around 6 to 13 problems. If the submissions of these problems are locked only during this short time, most of our problems would be solved and it might not have much consequence.
I see. Thanks for the clarification. I will revisit this idea sometime in the near future.
Until then, let me see how quickly I can get @Shahwat_Has9’s request implemented. It’s a very orthogonal feature, and has little impact on anything else.
I thought I would leave a little teaser of this feature here.
