Proposal
The feature to "star" or "favorite" a problem already exists; if you go to the problemset archive, you can choose to mark any problem as favorite. Same holds for marking any contest.
Unfortunately, it seems the only use for this feature, is so one could revisit his favorite problems in the future — you can't view the favorite problems of other participants. I think this feature can be easily extended to something more meaningful.
Maintain for each problem, the number of accounts who liked it (now referred to as the likeability of the problem). Then implement the option to filter (or sort) problems by their likeability (hopefully filtering problems by likeability could be combined with sorting by the number of people solved, so that people could find their own difficulty level). Same could go for contest likeability.
Pros
I think this can mainly help beginners. I hope that people who try out competitive programming for the first time, will first get intoduced to good problems. This way, they will get intrigued to solve more problems — I know this is what's gotten me and a few friends to invest into this branch. (Of course, this means that the option to filter or sort problems by likeability should be very apparent for any newcomer)
I believe this will improve the CF problemset as a source of practice, which is probably a main intention of this problem archive.
Cons
I can't find any at the moment. Feel free to point out some in the comments.
Side Notes
Perhaps Mike would want to weight the likeability marks, depending on the rating of people who marked it. This is open for discussion of course, but I think Mike would have better expertise in that area, so I'd like to hear his opinion.
Though unlikely, I suppose some people could create fake accounts to like their own problems, for unknown reasons. So, it could be implemented to include only rated accounts' marks into the likeability of a problem.
Contests' likeability could increase the contribution of all authors. Just a side note though.
Everything is open for discussion. You're welcome to throw in more pros, cons or side notes.
It would be a very helpful feature if implemented. Perhaps the weight of "likeability" could also depend on the number of problems solved by the person. Or more precisely on the problems solved of similar rating as the problem being voted.
Nice idea
I'd love to see this feature implemented!
To piggyback on this topic a bit, I'd also really like if there was a feature where I can filter the problemset to only show problems that I have solved. I've wanted this feature many times in the past, but the reason why I bring it up here is because I actually did not know that Favoriting individual problems was a feature and a filter like that would be really helpful for me to decide which ones for me to flag
This was actually something I also thought about recently. It would be useful not only for beginners, but for everyone, I think. In competitive programming as much as anything else, quality over quantity matters. When I tutor I always try to find the nicest problem that teaches an idea I want to teach and the likability feature would help with that.
But one problem with the idea, in my opinion, is that certain types of problems would be prioritised, specifically problems with a short code. From my experience and people I've talked to, a measure of likability is often "really creative idea that is simply in its essence". To get to a certain level in CP, I think you do need to do some more heinous problems.
Overall, I still think it's a great feature, provided there is a good enough search function for it.
You asked for cons:
People will start solving only 'liked' problems, which will be one-liners, "textbook" problems on well-known ds/algo, problems that not require deep thinking and problems which are easier than their assigned difficulty.
As a consequence people will practice in the above areas, which would negatively impact their learning progress
This shifts the mentality from 'given a problem find a solution' to 'given problems solve what you like'
The amount of negative towards problemsetters in round announcements will increase from 50% to 75%
What about people from purple+ range are capable of voting?
They will mostly vote for harder problems only and people will just complain of ratism.
I don't know. But, when you tutor a specialist/expert, then do you give them a bunch of 2200+ rated problems after you teach some techniques or something they can solve and learn new.
I agree with your first two points, as in, this is a possible scenario — if too many people mark such problems as their favorites. I find it unlikely though, if enough experienced users like you think otherwise, then you would like other problems that suit you. Still, it's very possible that new people will be directed to specific areas (not something I want). Hopefully this can be taken care of with, for example, weighing the votes of experienced users more (a comment above suggested to put more weight on the votes of people who solved more problems, which sounds like a good heuristic).
I'm not sure I understand what you're saying in the 3rd point... is it that you believe right now people encounter "the average problem", compared to facing only hand-picked problems (if the feature would be implemented)? If this is what you meant, I personally think that practicing on hand-picked problems is a better situation.
As for your 4th point, I don't understand where that's coming from... do you mind explaining?
In the 3rd point I mean that adding likeability (on the top of difficulty) will make people more picky about the problems they want to solve. All those measures (in my view) only serve to protect people from difficulties and make their journey as smooth as possible, but the smoother the journey is, the less things you'll pick up at it.
About the 4th point: community as a whole is very hard to please during the rounds. They complain about tasks being 1) too hard 2) too easy 3) too math 4) too long 5) too much code 6) too little code 7) whatever, especially if the rating decreased after the round. By making a selection of "liked" problems you'll make problems that people solve during practice and problems that people solve in real life (aka in contests) too different from each other.
Being a programmer, I value and raise in myself the ability to make a path where there was none. Without this ability, how will you be able to reach where nobody has reached?
As a side note, what would be a bad CP problem in your opinion? For me a problem is bad if:
Of all problems I solved on CF I can't remember even 10 which I would call bad/dislike.
I'd say "problem ratings" made inexperienced people picky about which problem they try to solve even though it's still not reflective enough of problem difficulty, leading to situations where people say "there's no way this is a 2800, it should be 2000" and "this 2000 is harder than most 2600 problems I've solved".
Not everyone use this feature to save favorite problems, I use this to keep track of the problems, that is too hard for me now and probably later I want to solve them. Or sometimes as queue of problems, that I want to solve later. And they are not necessarily my favorite problems.
I also use the star feature this way. I think this is a good idea, but it would have to be separate from the star feature.
Maybe we could simply extend the upvote/downvote feature for problems as well......
What if users are allowed to like/vote a problem only if they solved it during the contest? I don't know how this should be implemented for problems in the archive though.
Nice idea. One more thing that I guess worth mentioning is that problems of recent contests would probably have much much higher likability than older problems in CF which makes the fairness of this likability measure a bit iffy. In the long run this effect may eventually fade out though.
It is a nice idea for some aspect, but I think there are apparently "critical" cons for it, and we need to resolve this before adding this feature. I am writing this because it seems you are asking some cons.
In this 3 years, I think that the variety of problem set has became much narrower. In other words, problems is being classified as "good to be in the contest" or "bad to be in the contest" in main factor as genre or type of this problem. This is the same trends in CodeForces, TopCoder, and AtCoder.
For example, in last 3 years, string parsing problems practically became extinct. Also, the data structure oriented problems has decreased a lot in this time. On the other hand, contests now tends to focus on mathematics or combinatorics oriented problems. As a remarkable example, for 8 recent ARC-style contests in AtCoder, the last (sixth) problems for all of them are asking "count how many ways (mod 10^9+7 as an example)"-type, which is unbelievably biased.
Some people may think that, as seen in animals, the strong or the adapted will evolve and the others will be destroyed, and the evolved will make much variety, and they happens by turns. However, seeing recent times, I don't think that such problems are making much variety for the next step of selected evolution. In short, the contests are losing diversity.
If we can know the upvotes/downvotes system in (not contests itself but) individual problems officially, many people will "like" the liked problems. The "choice-and-focus" evolution step will accelerate, and it causes situation for example (it may not true!), "only combinatorics problems are important as regarded good in competitive programming" and "we should only try to practice them". This is which I call "problem type allergy". It is apparently not what the practicing of competitive programming should be, and in this aspect, it is not good for both solvers and writers.
If we can preserve what the entire practicing of competitive programming should be, it is a good feature. So I suggest considering about this problem before adding this feature.
Do you think adding a downvoting option for the likability feature is a good idea?
Cons: - people who did not solve a good problem could potentially down-vote it due to simply not being able to solve it and due to frustration. - people who didn't enjoy the contest in general (maybe even because of an issue not related to the quality of the problems) will deliberately choose to downvote all of the problems that appeared in the contest because of the issue without considering the quality of the problem in general.
Pros: More accuracy to the likability of a problem.
To deal with the "Con" I mentioned above, let's split the issue into cases:
Contests: - Enable downvoting only for people who participated in real-time and solved at least one problem - Enable upvoting only for people who either participated in real-time or took the contest virtually - For a person of rating 1899-, enable downvoting only 12-24 hours after the contest ended. - Weight downvotes based on score — if someone solved all problems and downvoted — their opinion has more weight than an opinion of someone who only solved a single easy problem. - Weight downvotes based on codeforces rating.
Problems: - Enable voting only for people who solved the problem - For a person of rating 1899-, enable downvoting only 12-24 hours after the contest ended. - Weight downvotes based on codeforces rating.
Reply to this comment in order to discuss :)