PieFed Meta

4771 readers

80 users here now

Discuss PieFed project direction, provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics.

Wiki

founded 2 years ago

MODERATORS

rimu@piefed.social

Improvement for the vote quota implementation (cake.kobel.fyi)

submitted 3 days ago by squirrel@cake.kobel.fyi to c/piefed_meta@piefed.social

50 comments fedilink hide all child comments

After a couple days of discussions about the newly implemented vote quota, I'm kinda exhausted. It seems like a situation we won't ever agree on. Me personally, I don't want to argue like this over a piece of software that I have high regards for. It tears us apart, where we should work together.

It's okay if there is a quota on piefed.social the instance.
It's not okay if there is a default quota of 240 on PieFed the software - and thus for all instances.

I suggest it should be implemented like this:

It should not be a default value
It should be an empty input in the admin interface, where instance admins can set a vote quota if they want to, or leave it empty to disable the vote quota.
The /about page should display the set vote quota.

That way all instances can decide for themselves and users can see the instances' vote quota transparently.

you are viewing a single comment's thread
view the rest of the comments

[–] ProdigalFrog@slrpnk.net 1 points 6 hours ago (1 children)

I personally can see there's some merit on both sides, where the change probably should've been more public and talked about before hand, and also that there can be some potential benefits to limiting votes in some fashion, since there are some instances where it's been misused, such as some people using it as a mark-as-read, sometimes with downvotes (I can't recall their username, but there was a user in the past who admitted to doing that, which I think has a negative overall effect since the first few votes of a new post have an outsized effect on if it gains traction or is more likely to be hidden).

I can't really see this having giant negative ripple effects throughout the fediverse/threadiverse since it effects such a small minority of users, but I suppose we'll see.

[–] OpenStars@discuss.online 1 points 5 hours ago

Directly, I agree with you: it will barely impact anyone at all. Something like 0.2% of the whole Threadiverse iirc.

Indirectly, it has already begun to impact all of us - e.g. anyone who enjoyed PugJesus, his memes or arguing with him or such.

There is also a huge amount of campism surrounding Lemmy v. PieFed, as if somehow both are not working side-by-side to make this place better than corporate enshittified media. And this gives ammunition to the anti-PieFed side to say how Rimu makes decisions without consulting the community first, injecting his personal political ideology directly into the code. I've already talked to several people about exactly that.

More arguments along these lines are coming and even if this voting suppression anti-feature were reversed today, those arguments will be long remembered in the Fediverse community, similar to how Lemmy handled the slur filter when it directly hard-coded it into the codebase and (at least initially, before MAJOR pushback) refused to make it an option that could be toggled off.

Some people will refuse to join PieFed as a result. Some, like PugJesus, may refuse to participate in the Threadiverse at all.

The ripple effects will be both as a result of the fact that PieFed is now performing voting censorship, and from the manner in which this change was released. An opt-in feature performing a similar task would have been GREAT here! Banning someone who spams votes is also a viable outcome - perhaps after a conversation with them to see if their usage was as intended or something odd that they may need coaching to do differently. But to summarily reject this submitted content with little to no warning is not welcoming at all.