A Case Study in Misaligned Incentives: The Polkadot UX Bounty

[josep]

@Faraday

I submitted several UX issues through the UX Bounty website in early October but haven’t received updates on whether or how they will be addressed. It would be great if community UX feedback could be more fully leveraged.

Thanks for bringing this up and for actually taking the time to submit issues.

In my original post I wrote:

@josep

I could also spend time explaining why other initiatives under this umbrella, like the “Data Analytics Program” or the “Community Feedback Program”, have been incredibly ineffective at best, or even actively detrimental at worst. But this post is already long enough

What you’re describing is exactly one of the parts I didn’t elaborate on to keep the post from turning into a book, so let me expand a bit now that you’ve raised it.

The “Community Feedback Program” is, in my view, another example of how this bounty operates in practice:

• The focus is on collecting and logging issues and being able to say “look, we have a community feedback pipeline and incentives”.
• Much less attention is given to actually driving those issues to resolution with the teams who own the products.

In other words, the incentives are set up to reward:

• Having a nice form,
• Creating a lot of buzz on social media,
• Having a public notion page,
• Being able to show numbers and screenshots in meetings,

…but not to ensure that the underlying problems are fixed.

From the outside, that plays very well in presentations (“we compensate users for finding issues”, “we have X feedback entries”), especially to people “upstairs” who aren’t close to the day-to-day (cough, W3F, cough). But if the reports then just sit there with no resolution, then well… we just lost an opportunity to actually fix them.

So I’m genuinely sorry that you took the time to report issues and got silence back. That’s exactly the kind of mismatch I was trying to point out.

Practically speaking, if you want those UX issues to be addressed, you’re usually better off going straight to the teams that actually own the products:

• If something is related to the polkadot-api libraries I (and my team) maintain, or to polkadot-js (which I try to help with in my spare time), I’m more than happy to at least take a look or help route it.
• Likewise, issues with specific dApps or sites are much more likely to get attention if they’re reported directly to those project’s repos/channels.

The people running this bounty can at best act as a broker or middle-man, and so far they haven’t shown that they can reliably close the loop between “community report” and “issue resolved”. That’s a structural problem with how the program is set up, not with you or your feedback.

Thanks again for sharing your experience here. It’s useful concrete evidence of the gap between the narrative and the actual outcomes.