Not quite what you asked, but in general I take the approach of fixing bugs before doing new feature development. Building on a buggy foundation is only going to cause more headaches in the long run.
If you are choosing by difficulty, I'd say "Eat the frog" and start with the most difficult. But I would also un-ask the question and say "is difficulty the right metric for deciding priority?" For me, it isn't.
First, I'd start with what's urgent. What is hurting your customer's experience and your company's bottom line by the minute?
From there, I'd work on what's most important. What's going to deliver the most value to the most amount of people. If it take you 15 minutes to fix a bug that's a huge inconvience for most of your users, it makes sense to tackle that over a feature that takes weeks to build, especially if you aren't clear how popular it would be.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Not quite what you asked, but in general I take the approach of fixing bugs before doing new feature development. Building on a buggy foundation is only going to cause more headaches in the long run.
If you are choosing by difficulty, I'd say "Eat the frog" and start with the most difficult. But I would also un-ask the question and say "is difficulty the right metric for deciding priority?" For me, it isn't.
First, I'd start with what's urgent. What is hurting your customer's experience and your company's bottom line by the minute?
From there, I'd work on what's most important. What's going to deliver the most value to the most amount of people. If it take you 15 minutes to fix a bug that's a huge inconvience for most of your users, it makes sense to tackle that over a feature that takes weeks to build, especially if you aren't clear how popular it would be.