- Edited
I wince a bit when the conversation shifts to managing negative impacts around politics and user bias. My personal strategy for socially charged features such as this, is to maintain awareness and rigorously architect a solution that bias-free enough that there's not really anything in the delivery pipeline to point at as evil or unfair.
examples: (i'm just exploring possible foibles, not suggesting implementation here)
1: I choose "users who love github" as a sentiment pool to enable. I review the upvote-only list and see that stack exchange and some others are also prioritized. Why isn't devdocs.io listed? dunno, maybe i should upvote it and get others checking it out!
2: I choose "users who love github" as a sentiment pool to enable. I review the upvote/dowvote list and become offended that devdocs.io is deprioritized. the nerve of these kagi users, would do such a thing. I'm upvoting it.
3: I can't wrap my head around what a downvote-only capability would look like - insert downvote-only scenario here. why is devdocs.io deprioritized? this is ludicrous. it's just a reference agregator. I might just go chew someone out on kagifeedback. this is unacceptable.
I chose to use the "Users who also love" sort of paradigm very intentionally earlier in the thread. It's hard to target percieved political bias when the dimensions of grouping have nothing to do with politics. Sure there would be biases within user's shared sentiments, but they might be bucketized in a way that diminishes that impact perceptually and functionally.