Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't have users "own" tags, just edit them like other shared data #915

Open
dfabulich opened this issue Oct 23, 2024 · 3 comments
Open
Labels
needs discussion It's not clear how to begin/finish this tagging Improvements in IFDB's tags

Comments

@dfabulich
Copy link
Collaborator

dfabulich commented Oct 23, 2024

Today, users "own" their tags. You can delete your own tags, but not anybody else's.

Instead, the tags should just be an ordinary, shared fact about a game, like the game's description, genre, or external links.

You should edit them on the editgame page, submit changes (including deleting anyone else's tags), and have those changes appear in edit history.

@dfabulich
Copy link
Collaborator Author

A bit of history about why users can only delete their own tags:

Originally, IFDB had this notion that multiple users could assign the same tag to a game, effectively "voting" for the game having that tag. So if a bunch of users all tagged a game "surreal," then we'd know that the game was more surreal than games where just one or two users tagged it surreal.

IFDB even used to have a thing where it would show two numbers next to a tag, e.g. "IF Competition 2001 (3/22)". There was a little help document that explained:

What do the tag numbers mean?

There are two numbers in parentheses listed after each tag in a game listing. For example:

IF Competition 2001 (3/22)

The first number is the number of other people who added the same tag to the game. (Why bother adding a tag someone else already added? It's basically a vote for the tag: it strengthens the tag's association with the game. This improves the search engine by telling it that the game is that much more relevant when someone searches for the tag.)

The second number is the number of other games with the same tag. You can see the full list by clicking on the tag.

But, quickly, it became clear that this isn't how anybody actually uses tagging.

Once anyone tags a game "surreal," there's very little reason to tag it surreal again; it shows up in searches for tag:surreal if even one person tags it that way, and there's never been a feature to sort by the number of people who assigned a game that tag.

Furthermore, this had odd effects:

Soon after tagging launch, MJR removed the two numbers, and just showed the second number, but left the schema in place, so users still own their own tags.

By managing tags as ordinary game data, it will be visible who added a tag, easy to manage history, and make it possible for ordinary users to clean up tags.

@dfabulich
Copy link
Collaborator Author

There was a thread about this on the forum. https://intfiction.org/t/uncontrolled-tag-deletion/72117

I thought about this a bit harder and I do kinda see otistdog's point here.

People don't go messing around with external links because they are matters of objective fact. But tags are judgment calls. Is this game surreal? Is it horror or is it just spooky?

And then there's tag consolidation. You could imagine someone bulk adding and bulk deleting a bunch of tags using the API, and even getting in edit wars about them, in a way that I don't think is likely/plausible for description, external links, etc.

I'll keep thinking about what I want to do about this.

@dfabulich dfabulich added the needs discussion It's not clear how to begin/finish this label Dec 4, 2024
@dfabulich
Copy link
Collaborator Author

Today, I feel more inclined to do tag voting, in the style of VNDB. #1195

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs discussion It's not clear how to begin/finish this tagging Improvements in IFDB's tags
Projects
None yet
Development

No branches or pull requests

1 participant