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

[Request] More plugin info on store page #566

Open
3 tasks done
wallentx opened this issue Nov 24, 2023 · 3 comments
Open
3 tasks done

[Request] More plugin info on store page #566

wallentx opened this issue Nov 24, 2023 · 3 comments
Labels
feature request a request for a feature, no guarantee of addition

Comments

@wallentx
Copy link

Please confirm

  • I have searched existing issues
  • This issue is not a duplicate of an existing one
  • This is not a request for a plugin

Feature Request Description

I've been using this for a few months, and there are a few items that I think are important to have:

  • The date of the tag/version of the plugin
  • A way to flag/report a plugin as broken/orphaned
  • An indicator of some sort showing that the selected tag/version of a plugin has been reported as broken/orphaned
  • A comment system- to comment on, and read comments about a plugin
  • A rating system, perhaps based on a +1 system, which can only be voted on if the plugin is currently installed

Further Description

Much of the thought behind all this is inspired by using AUR helpers, like how yaourt was great at displaying relevant comments about a particular package release. I also think the plugin store is in need of some of these items due to the nature of SteamOS updates breaking things.

My DevOps brain is telling me that this could all be made leveraging GitHub issues/discussions as a backend, if there was no interest in maintaining infra to support any of these.

I'm happy to help, but just wanted to present these items to see if there was any interest in some/all of these things.

@wallentx wallentx added the feature request a request for a feature, no guarantee of addition label Nov 24, 2023
@PartyWumpus
Copy link
Member

Thanks for the suggestions.

The date of the tag/version of the plugin

The date of each version is sent by the store, so this would be a reasonably trivial frontend adjustment.

A way to flag/report a plugin as broken/orphaned
An indicator of some sort showing that the selected tag/version of a plugin has been reported as broken/orphaned

This is an interesting idea. Right now the closest system to this is just hiding a plugin from the store, which has the major downside of not reporting anything to users of a broken plugin.

A comment system- to comment on, and read comments about a plugin

I don't love the idea of having to moderate a comments system, but using github issues might be fine. The current system is the discord server, which is not the best solution.

A rating system, perhaps based on a +1 system, which can only be voted on if the plugin is currently installed

A rating system has been considered in the past and (imo) would probably not be worthwhile. A download counting system has recently been implemented so I think that would serve a similar enough purpose if added to the frontend.

@wallentx
Copy link
Author

This is an interesting idea. Right now the closest system to this is just hiding a plugin from the store, which has the major downside of not reporting anything to users of a broken plugin.

I saw the testing process that is currently in place for getting plugins into the Decky Plugin Database, and thought that maybe something with that workflow could act as the source of truth. I also saw that GitHub Projects is set up in a very nice manner 👍

I did a mockup of how something like this could go:

An issue template specifically for Plugin flagging - https://github.com/wallentx/decky-plugin-database/blob/main/.github/ISSUE_TEMPLATE/PLUGIN-ISSUE.yml?plain=1

From the decky-loader store plugin page, or store page, there's an option to flag the plugin as broken, which if selected, is a pre-filled URL (I found this project, but I'm sure there's a ton of ways to do it https://github.com/sindresorhus/new-github-issue-url) to create a new issue, and automatically fill in the plugin name, plugin version, steamos version, or whatever else might be relevant - wallentx/decky-plugin-database#2

When the issue is created, it is also automatically added to the SDH Tracker project board, and also has a plugin-flagged label automatically applied - https://github.com/users/wallentx/projects/3/views/8
This view can essentially act as the data source for a plugin rendering as broken or whatever.

The custom fields I spawned pretty easy with either of these (I'm not sure which is technically considered more "current"):
gh project field-create 3 --owner "@me" --name "Plugin" --data-type "SINGLE_SELECT" --single-select-options "$(curl -Ls https://beta.deckbrew.xyz/plugins | jq -r '[.[] | {key: (.name | ascii_downcase), value: .name}] | sort_by(.key) | map(.value) | join(",")')"

gh project field-create 3 --owner "@me" --name "Plugin" --data-type "SINGLE_SELECT" --single-select-options "$(grep 'path = plugins/' .gitmodules | cut -d'/' -f2 | sort | tr '\n' ',' | sed 's/,$//')"

Anyway, I was just poking around at the new Projects features and used this as an excuse to learn them.

@JohnEdwa
Copy link

A rating system has been considered in the past and (imo) would probably not be worthwhile. A download counting system has recently been implemented so I think that would serve a similar enough purpose if added to the frontend.

An endorsement/+1/thumbs up system like on Nexus Mods etc is actually rather useful because it allows you to distinguish between something popular and something that users actually like to use. Even if something doesn't work or isn't actually good, the higher it sits in total downloads the more likely it is that someone new downloads it as well adding to that count - but they wouldn't then recommend it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request a request for a feature, no guarantee of addition
Projects
None yet
Development

No branches or pull requests

3 participants