Clarify the contributing guidelines for the main list versus MORE.md#263
Open
Rangi42 wants to merge 2 commits into
Open
Clarify the contributing guidelines for the main list versus MORE.md#263Rangi42 wants to merge 2 commits into
Rangi42 wants to merge 2 commits into
Conversation
avivace
requested changes
Jun 9, 2026
| That last criterion is the most subjective one, but it's what distinguishes this list from being a raw collection of everything related to Game Boy development in general. Don't take the name too seriously -- not being on the list doesn't mean your project *isn't* awesome, and vice-versa, but we would rather leave things out than include too much. | ||
|
|
||
| If the resource is in another language, still work in progress, abandoned or you don't think reaches the described standard BUT it's still related to Game Boy development/hacking you can add it to the **MORE.md** file. | ||
| Historically there has been some tension between this list being a curated subset of "awesome" resources, and being a comprehensive set of all reasonable resources. For the latter, cases which don't *quite* make it to the main list, we have [**MORE.md**](MORE.md). If the resource is in a non-English language, still a work in progress, abandoned, or doesn't reach the described standard *but* is still related to Game Boy development/hacking, then you can add it to the **MORE.md** file. |
Member
There was a problem hiding this comment.
I'd drop this. It doesn't add anything actionable for contributors and reads as internal history/drama that doesn't belong in a contributing guide.
Contributor
Author
There was a problem hiding this comment.
I didn't realize that this division had caused drama in the past. I'll try and reword it to keep the explanation of what MORE.md is for.
Member
There was a problem hiding this comment.
I mean, that's what Historically there has been some tension would suggest
Contributor
Author
There was a problem hiding this comment.
I removed that lead-in, does it sound better now?
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #262
Currently the guidelines link to issue #96 for "discussion" of the criteria for adding a resource to the "Awesome" list. I think this could be more helpful -- issue discussion is inherently premature, with potentially conflicting viewpoints being hashed out, and not being part of the actual document implies that it's not essential to read.
Meanwhile, the criteria actually listed in CONTRIBUTING.md don't quite clarify why a project wouldn't "deserve" to be on the Awesome List, despite meeting the (lenient) criteria we list. A "minimal working state", "minimal documentation", "something interesting" -- most people's projects already meet that qualification.
Of course, the issue #96 discussed this exact tension, between this list as a curated set of widely-useful resources, versus being "a raw list of everything related to Game Boy (Development) in general". If we want MORE.md to be for the latter, I think that should be stated explicitly, so I opened this PR to do it.
(As it currently stands, it sounds like MORE.md is for incomplete, buggy, abandoned work -- which as far as I know is not the intention. It's not a dumping grounds for work not even good enough to be on the main list. It's a place for work which fails some essential criterion of the main list, but makes up for it in other ways, e.g. a high-quality popular tutorial that happens not to be in English, or a half-finished demo that still shows off some unique trick.)
I borrowed some of the phrasing here from people discussion in that issue. Maybe more of it should be here. Before reading over its comments, I had inferred that the "awesome" list is for widely useful, technically interesting, historically relevant, or already popular links. Maybe those really are our general criteria, so we could spell them out here. But ISSOtm actually critiqued "historically important" in that issue: "From a preservation standpoint, yes; from a usability standpoint, not if it has been improved." So maybe we should explicitly state that historic but supserseded resources belong in MORE.md. (And review what's currently on the list since some of it maybe ought to be moved there by now.)