I'm sure I could do it, but I've no idea what kind of effort it will take me to get familiar with Condenser and make such a change.

Do you mean something like finding the code for this element...

... and altering it to be something like this?

And then inverting the linear 100-10000 scale into a logarithmic 10000 - 100 in the background (technically a 100% upvote is 10000 weight and 1% is 100 weight).

To get any meaningful information out of it though you'd then need to test it on a bunch of people either by A/B testing it on Hive.blog or with a focus group.

Even then, in truth the big voters are auto-voting anyway, or delegating to curators who understand the underlying mechanics well enough.

Edit: After getting responses to this post, I no longer think we can fix the issue just with front end changes, as the cap would create problematic disincentives for curators. IMO, an upvote should have always had a recommended reward level attached, and the final reward should be based on the stake-weighted-median of recommended rewards. Curation rewards would also have to work differently in this case. However at this stage of the project I'm not sure if there's much value left in trying to continually readjust the tokenomics with hard forks either 😕