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

Clarify and document quality control for games #352

Open
svetogam opened this issue Aug 27, 2024 · 0 comments
Open

Clarify and document quality control for games #352

svetogam opened this issue Aug 27, 2024 · 0 comments

Comments

@svetogam
Copy link
Contributor

svetogam commented Aug 27, 2024

CONTRIBUTING.md has a note saying "The scripts, add-ons or plugins must be useful in a project." It doesn't say anything about games, though some kind of quality control is applied, as I found out in #342.

It's frustrating to have your game rejected, and it can also slightly waste developers' time being unclear about what state their game should be in before they try to add it to the list. So I propose to add a similar note for games as for scripts.

What this note should be will depend on the purpose and principle of this list.

From what I can tell, my guess is that the implicit current quality control values the game being more complete and presentable. This makes sense if the purpose of the list is to showcase Godot or to curate games for players. However, since these are FOSS games and it is mostly developers looking through this list, I don't think this is an appropriate kind of quality control to have.

My preference would be to include anything purporting to be a game with at least some interesting code that solves at least one interesting problem. This would best fit developers' wants of having as wide a pool as possible of code they could borrow. (One outcome of this rule is that simple cookie-cutter games that are boring to me would be excluded. But again, this is just my preference and I don't insist on it.)

I can add that requiring a game to be presentable or playable before developers can share it here with other developers suggests what I consider to be some inefficient development practices. But I would be speculating that it actually is presentability that is the form of quality control being currently applied, so I'll wait for clarification before arguing further against it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants