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

"Awesome" quality standard #96

Open
avivace opened this issue May 20, 2018 · 9 comments
Open

"Awesome" quality standard #96

avivace opened this issue May 20, 2018 · 9 comments
Assignees
Labels
meta Changes on the structure list, general meta discussions

Comments

@avivace
Copy link
Sponsor Member

avivace commented May 20, 2018

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":

  • Be in a minimal working state
  • Have a clear purpose and/or provide something different
  • Have a minimal documentation/README providing at least a brief overview of the project

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?

@avivace avivace added the meta Changes on the structure list, general meta discussions label May 20, 2018
@ISSOtm
Copy link
Member

ISSOtm commented Jun 15, 2018

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.

@tobiasvl
Copy link
Member

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

@avivace
Copy link
Sponsor Member Author

avivace commented Sep 30, 2019

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

@pinobatch
Copy link
Member

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.

@ISSOtm
Copy link
Member

ISSOtm commented Sep 30, 2019

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.

@pinobatch
Copy link
Member

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

@deltabeard
Copy link
Contributor

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.

@stuaxo
Copy link

stuaxo commented Sep 30, 2019

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

@avivace
Copy link
Sponsor Member Author

avivace commented Sep 30, 2019

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 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Changes on the structure list, general meta discussions
Projects
None yet
Development

No branches or pull requests

6 participants