I am facing some challenges writing editorials for a round. Some of them were discussed in this blog.
Now I am preparing my second Div. 2 contest (which is going to take place soon!) and I came to a point, where I want to start writing the editorial for the problemset.
My first contest was a total success in terms of editorial, it got heavily upvoted. Here are some key factors, which might have to do with it:
- Problems. First and foremost, if the people were to hate the problems, it would definitely affect the rating of the editorial. Good problems are an essential part.
- Timing. I published the editorial less than a minute after the contest, so more people would actually read it. Don't be like tourist in the recent rounds :D
- Hints and spoilers in general. The editorial doesn't look messy, you can open only the tasks you need and hints are a great thing when trying to actually improve reading an editorial. Treat hints as if they're as important as the problem statements.
- Implementations. My approach here was based on not copy-pasting the code to the blog, but actually making all the needed submissions after the contest and then add the links to the editorial. This way one could actually see, that the code is working, not look at some plain (or colored) text. This took a few hours, since you can't submit before the system testing is done. I had solutions in both C++ and python, which is nice for python CPers.
- Responsiveness. There will be typos and bugs in the editorial, listen to the people, that are trying to point them out. Even the small inconsistencies might affect the understanding of a bunch of people. Especially the last problems, which are often overlooked, since very few actually read it.
There are a few adjustments that I might propose for codeforces team:
- Let us add solutions for the problems beforehand, not after the system testing. By this, I mean automatically give access to the pre-written solutions after the round ends (I know you already make the submissions to test beforehand, just make them public).
- Post the editorial automatically after the round ends.
I have questions to the more experienced problemsetters:
- How do you synchronize editorials in Polygon and Codeforces blog? I like the idea of keeping everything in one place, which is Polygon for me. But with every small change I have to paste it to the blog by hand. Like, this is cringe.
- How do you write editorial with spoilers in Polygon so that it doesn't say
use quotes like ``text'' instead of "text" in tutorial. I am a perfectionist, I don't like this warning :(
Any other advice would be highly appreciated.
Strongly Agree !!!
thanks for helping the community
He's got a point!
Use [tutorial:727G] to show the Polygon editorial for 727G for example.
Thanks, that's actually useful, but doesn't compile my previous editorial because of mathjax somehow. Will investigate.
Also, how to change errors in the editorial? Does it pull the changes from Polygon?
It does after you build a new problem package (or in 10-20 minutes from that moment)
When and who publishes the editorial? Since timing is crucial imho, you'll need someone to let
[tutorial:XXXXY]be public, otherwise it is easily hacked :)
Can you share your text paste for some problem in https://codeforces.com/blog/entry/106675 (the blog itself would also be very useful)? The blog looks fantastic (besides my point for implementations).
Also, do you have any solution for warnings using spoilers? It just bugs me so much.
Here you go (removed implementations to reduce clutter, hopefully).
I don't know of any way to put spoilers in Polygon itself, that's why for some of the problems I had to copy paste the editorial from Polygon. It would be really cool if we could put spoilers in Polygon...
I'd like to use this opportunity to mention another thing that in my opinion, is important in an editorial:
I prefer it much better when the solution explains the steps the author took to solve the problem, rather than arriving at sudden observations, and only later you can see how they relate to the problem. Many authors like to provide the "shortest path" to the solution, resulting in a few lines of a solution that generally require me to read them at least 3 times to understand (some university professors also like to provide such unintuitive proofs, without the thought process behind them).
I believe that if a person fails to solve a problem, it is best to read the editorial only after the person took a sufficient amount of time to be stuck with their ideas. In a way, I like to think about problem-solving as a tree of approaches: when someone is stuck with all of their approaches, then he requires a large amount of work to extend any of the nodes to more ideas. Thus I think the best editorial is one where you can comprehend the approaches the author took, and can compare the text you read to your tree of approaches, until at some point the editorial shows you how to extend one of your ideas to a complete solution, increasing your capability for the next problem. Comparing that to "shortest path" solutions, I think they can come up with ideas that don't relate to anything your tree of approaches has, and you (or me, personally) learn less about how to generalize the solution and more about a single trick (that you may forget).
It may not be perfectly possible with every problem but I think this is what authors should aim for.
Totally agree, though I personally believe that hints should do the job. For example, a hint saying
Can we apply binary search to find the answer?is practically one of the questions eventually leading to a full solution.
Although designing actually good hints is hard, the author must have every intention of doing so.
Now that I'm thinking about it, with some polishing this blog can make it to the Catalog.