"Awesome" quality standard about awesome-gbdev HOT 9 OPEN

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
To quote:

Only put stuff on the list that you or another contributor can personally recommend. You should rather leave stuff out than include too much.

As for "what is awesome", I agree with the guidelines proposed above. I summarize them in this way:

• If it's widely used, then it should be included.
• If it's unique (eg. the only emulator available for its platform, or a great reference implementation, etc.), then it should be included.

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.

from awesome-gbdev.

If you want a word then legacy is fine for superceded stuff.

from awesome-gbdev.

Of course closed-source software should be linked! It would be absurd not to feature BGB on this list.

from awesome-gbdev.

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.

from awesome-gbdev.

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).

from awesome-gbdev.

This is becoming more relevant now, in light of recent events.

1. Should we set a procedure for voting a controversial resource to be considered awesome or not?
2. Should we assume something is not "awesome" just because some part of it is using "non optimal" software or routines or pattern? (E.g. tutorials not using BGB being "not okay").

from awesome-gbdev.

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.

from awesome-gbdev.

Should we set a procedure for voting a controversial resource to be considered awesome or not?

Sounds reasonable if we want to avoid decisions to be considered arbitrary, I suppose.

Should we assume something is not "awesome" just because some part of it is using "non optimal" software or routines or pattern? (E.g. tutorials not using BGB being "not okay").

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.

from awesome-gbdev.

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 .

from awesome-gbdev.