godotengine / godot-asset-library

PHP frontend for Godot Engine's asset library
https://godotengine.org/asset-library
MIT License
292 stars 87 forks source link

Asset versions instead of asset edits [Request For Comments] #143

Open bojidar-bg opened 6 years ago

bojidar-bg commented 6 years ago

This issue potentially supersedes issues #92, #93, #94, and #109. It will also invalidate #64, #71 and a few other issues related to asset edits.

Comments are welcome.

TL;DR

In short, asset edits are too confusing for users, so I propose to replace them with much more intuitive asset versions, which will not include previews and descriptions, but just the download information.

Motivation

Over the last few years, many users have used the asset library (450 registered, 113 active), creating as many as 166 assets and 516 edits. Of those edits, 94 (~20%) have been rejected, mostly because of confusing policies, duplicates, empty edits and similar problems. About a third of all people who have submitted an edit have had one of their edits rejected.

This shows that the flow is likely not intuitive enough and that it might be causing frustration and additional trouble to asset contributors.

Some additional problems stemming from the edits concept:

  1. People have to wait for moderators to calculate hashes and accept their edits. While it is good to have some moderation, something a bit more open might be better.
  2. It is hard to see previous versions of assets since we only store the edited fields.
  3. It is hard to make an auto-installer for the Godot editor since newer versions of assets might break compatibility (including compatibility with the version of Godot itself).
  4. It is currently impossible to install a "preview" or "testing" version of an asset from Godot.

Since we are currently refactoring and revamping the asset library (see #82 for details on that), it seems to be around the right time to change the concept of edits.

The proposal

Therefore, I propose to remove asset edits, except for historical versions, and instead provide asset versions. An asset version would contain a download URL, a content hash, and a moderation state (Untested, Accepted, Rejected). The download URL and content hash will be removed from the asset itself. The moderation state might be removed at some point, in case we decide that the risk of people submitting malicious assets is less than the cost of moderating all the versions. Asset edits are not going to be moderated now, and might even be dropped altogether. Alternatively, we might leave them just to keep the history of recent edits.

willnationsdev commented 6 years ago

Would we still be able to associate multiple asset versions with the same asset? So we aren't simply submitting a ton of different versions to the asset library in general? Or was that your intent all along?

eon-s commented 6 years ago

If assets have dependencies like mentioned in the referenced issue, with a versioning system these can "safely" set a max supported version.

bojidar-bg commented 6 years ago

@willnationsdev ~ Yes, that's my intent with this RFC. @eon-s ~ I guess, yea.