Hello Codeforces.

Just a reminder about something most of you know. Polygon is a service to prepares programming problems and contests. It is usually used to prepare problems for olympiads/programming contests but it is also often used to prepare educational content. It is located at https://polygon.codeforces.com/ and is open to everybody.

I have recently found out that it's been more than five years since the creation of Polygon. It's high time to summarize the experience we've accumulated.

I first publicly spoke about Polygon in a narrow circle of Russian teams' coaches on ACM-ICPC World Finals in 2009. I cannot say that everybody was enthusiastic about the innovation. Some people were openly skeptical about such system's viability and relevance. After 5 years on the ACM-ICPC finals in Ekaterinburg Oleg Hhristenko (snarknews) said that in his opinion, the creation of Polygon is more of my achievement than Codeforces. Of course I was surprised but I said so to Polygon :-)

When I started working on Polygon (in the autumn of 2008), I understood very well how much this system was needed. By that time I had already been an experienced writer of many problems. The infinite number on highs-school Saratov Olympiads and ACM-ICPC Subregionals. My problems were on the All-Russian Team School Student Olympiad in Programming, the Russian National Olympiad in Informatics (for High-School Children), the ACM-ICPC NEERC Regionals, the TopCoder Open Finals and many other places. In most cases the problems were developed in some VCS (e.g. SVN) everything was structured by some half-formal unspoken naming rules.

I am going to give you some thesis statements on why it is good to use Polygon and bad not to.

1. Polygon protects from errors

Polygon is full of automatization, self-checks and verifications. Some examples:

• it is hard to make a misprint in a sample input/output and forget to actualize it after the tests are changed as it is inserted automatically and the answer is generated by Polygon using the model solution;
• it is hard to leave a non-compiling solution in the archive (even experienced teams like ITMO regularly leave the solutions on Java in the archive where the name of the class doesn't match the name of the file);
• it is hard to forget to make the first test the statement test, Polygon would warn you about it;
• it is hard to write a generator that is initialized from time and thus it prints different tests on consecutive invocations (i.e. not stable), Polygon will run the generator a couple of times with an interval of one second and check if the tests match.

2. The archives (packages) of the Polygon problems are uniform and machine-readable

It's striking that the olympiad community hasn't standardized a method to distribute problems. The problems from Polygon have a uniform and logical way of organizing files and are machine-readable. File problem.xml contains not only the basic meta information like memory limits, but it also has everything you are going to need for the continuing work at a problem. Here are some examples:

• for TL it shows the type of the processor for which the TL was chosen;
• it clearly shows the IO method and file names (if used);
• it supports multiple native languages in for problem title/statements;
• It has an exact way to generate each of the generated tests;
• solution tags (for example, a deliberately slow solution can be tagged as time-limit-exceeded);
• precise paths to tests and other resources.

I don't know any other machine-readable descriptor formats in use that are so complete.

3. Polygon stores files for long-term and keeps them available

I can open the problems of the ACM-ICPC Saratov Subregional 2009 and edit a test. Everybody who has access to the problem can do the same. All the changes will be visible to all the coauthors, they will be notified via email and the automatic testing systems can get the changes when new problem package is built. I can run the solutions as I edit, all tests will be validated, all the solutions will be ran. But what happens if you don't use Polygon? For the time of contest developement a local version control system is used, it is usually shut down later and only the archive remains: we lose editing history, developing access, automated invocations and other things.

4. Polygon decreases the barrier to entry the problem preparation process

The Codeforces problem writers are the contest participants of different level of training, cultural and professional background, for many of them it's their first experience of preparing problems. They almost always easily understand what to do and how to do it, they can add problems. If you don't use Polygon, then the process is usually regulated by a system of unspoken rules (like, add suffix _slow, or _tl to the title of the slow solution), an unexperienced participant gets lost and cannot understand what to begin with and how to work. Besides, it usually requires some knowledge of basic principles of working with svn and command line and work differs for the Windows and Linux users.

5. Polygon helps you manage access

In Polygon you can give access to the problem to any registered user. If you work without Polygon, it is usually done by the version control system server administrator and you don't even have the list of your co-authors. You cannot manage access on your own, the access is usually managed at the contest level, not problem level.

6. Polygon has issue-tracking

When there is more than one developer working simultaneously, they absolutely need to be able to add and manage issues. Besides, issue-tracking is useful in individual work as well. It structures work, helps you not to lose track of the details. Whenever I've worked outside Polygon, the best task management I saw was a special file with a numbered list of tasks.

7. Polygon is easily integrated with online judges

Polygon offers machine-readable problem packages with prepared tests (for both Windows and Linux) or enables to generate them at package deploying. Polygon has a simple HTTP POST-based API to access data. While POST-queries are formed, you need to set the user's login and password parameters (and optionally, revision).

• https://polygon.codeforces.com/p/username/problemname — download the last package (unless the revision is defined);
• https://polygon.codeforces.com/p/username/problemname/problem.xml — download the descriptor from the last package (unless the revision is defined). For example, in order to see that the revision has changed and we need to re-download the package;
• https://polygon.codeforces.com/c/contestid/contest.xml — download the descriptor of the contest
• https://polygon.codeforces.com/c/contestid/english/statements.pdf — download the PDF with statements in English, all the statements are listed in the contest's descriptor.

Say no to manually copying problems into the judging system, let the system upload the problem for you and deploy or update it.

8. Without Polygon the developer needs to have some special soft on his PC

For example, a developer with Windows may need bash to run doall.sh that generates all the tests. Or a Java programmer will have to install C++ to compile the checker. Use LaTeX to compile the statement. Polygon sets you free from all of that, lots of work is done on the side of the server.

9. Polygon is safer than most alternative ways of shared development

Polygon uses HTTPS, you can attach browser session to IP-address (it is optional, of course), session is attached to User-Agent, we use CSRF-tokens everywhere.

10. Polygon classifies and indexes problems

You will never get lost in problems. I have about 500 problems in Polygon made by me only, but due to tags, filters, search and sorting into contests I never get lost in them and can quickly find what I need.

The End

Those are only the first reasons that came to my mind at 2 AM. I am sure that we can come up with some more of them after some thorough thinking.

The conclusion is simple. Every time you make a problem not in Polygon, god kills a kitten.