-
-
Notifications
You must be signed in to change notification settings - Fork 180
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
"Awesome" quality standard #96
Comments
I'm bumping this, because I would like to submit a PR with a draft of the separation. Thus, I would like to know what kind of split would be preferred. So, yes, I agree with the split, especially because it's part of the awesome list guidelines
As for "what is awesome", I agree with the guidelines proposed above. I summarize them in this way:
I make a point that closed-source software should be linked to as well. Someone pointed out that closed-source software may not be cross-platform, but if it's widely used anyways (BGB being the most egregious example), it would be unfair to not include it. When it comes to picking, I'd say to go for the most complete/readable/usable/etc. And, in case where, say, one thing is more up to date but the other is more user-friendly, I think both should be linked to, since they appeal to different publics. |
Of course closed-source software should be linked! It would be absurd not to feature BGB on this list. |
This is becoming more relevant now, in light of recent events.
|
And can something be "awesome" if it requires the use of proprietary software available only for one proprietary operating system or instruction set? For example, bgb can run under Windows or Wine on x86 and x86-64, but not on ARM. This means the owner of a Pinebook laptop won't be able to complete a tutorial that relies on bgb, and the owner of a Raspberry Pi pocket desktop will have to buy an Intel NUC. |
Sounds reasonable if we want to avoid decisions to be considered arbitrary, I suppose.
First, let's get perfection out of the way: nothing is perfect, if only because nobody has found a definitive way to do GBDev. Each have their own constraints and tastes (concrete example: the HGBASM VS Code extension is great for a variety of purposes, but my PC throttles from overheating when running VS Code). Therefore it'll have to be a subjective measure of "good enough". I'm having trouble defining what is awesome, but I have an idea of a criterion that automatically makes something not awesome. If something has a glaring flaw (code that hardcodes locations, incorrect docs, security-flawed emulators, ...) then it does not belong to the list, period. Exceptions can be made if no alternative exists. As for the problem Pino posed, if a tutorial is specifically about BGB or other proprietary software, I believe it's probably fine; ideally there should be an alternative, and/or a more generic tutorial, but then this is just a collection of links. Finally, I'm conflicted about one thing: should something historically important be considered permanently awesome because of that? From a preservation standpoint, yes; from a usability standpoint, not if it has been improved. Personally I believe the goal of the list is the former, and that the latter should be handled separately. |
I guess if something is historically awesome but has since been replaced, such as a VBA-centric debugging tutorial that hasn't been rewritten for mGBA, it can be called "super" (short for superseded). |
I don't think that's a good idea since "super" is a synonym for excellent. A definitive list of articles and links could also be considered as "awesome", instead of the items in the list being awesome themselves. Maybe each item, or "not as awesome" items could have a comment regarding its accuracy, correctness, etc. I also think that comments or votes regarding the inclusion and exclusion of items should be exclusively posted on here, instead on the Discord channel. People on the Discord channel seem to be more critical of works, and sometimes comments of an unwelcome nature. |
If you want a word then |
Interesting points. About the voting procedure: should we elect a group of people having this power? So in case of controversial resource we can call the vote? Update: The group of people having the vote power is @gbdev/awesome-gb . |
Context: The list started as a collection of "awesome" resources and ended up in being a raw list of everything related to Game Boy (Development) in general. The idea is to thin the main list a bit, moving the WIP, incomplete, not documented and generally not providing a real contribution entries to another page, called MORE.md.
I think that they need to reach a certain "quality standard":
How do you think we should discriminate the resources? What makes a resource "awesome"? What is a perfect example of an "awesome" resource and what is not?
The text was updated successfully, but these errors were encountered: