Home

Guidelines for contributors

Anyone is free to contribute new lines to the repo. For those wishing to push new software or updates, this is the format you should follow:

(Emulator) Hardware Emulated | Formal App Name | [VersionNumber_Date-of-release](Release OPK or Release Page link) | [StateOfDevelopment](Source code link) | Does software require data files? If so and required, put here - if so and it's optional, please note it as such; else, put 'No'

[StateOfDevelopment] can be one of three statuses:

• Active: App is in active development, and is expected to receive either new functional or aesthetic updates. If you're the main contributor/developer of the app in question, this should be the default.

• Inactive: App is in somewhat active development, and has plans for new updates in the future, but has either stalled considerably or some other condition that has prevented contribution for a long period of time. This most implies an app that's a work-in-progress from another system (such as a GCW Zero project that may need updates for new hardware like the RG-350), and needs more or new contributors.

• Legacy: App has either concluded development, or the main/supporting contributors have since abandoned the project, or there is no source provided which prevents further development from other contributors. This implies, for one reason or another, that the app in question is being provided for archival or historical purposes.

For release links to currently running projects, it should be pointing to a repo's release page (like https://github.com/User/MyRepo/releases/latest). This will reduce the needed upkeep as it will always point to what's considered the 'latest' release. Don't use direct links to raw files; if a release page has necessary information for the user to read, this is necessary information and shouldn't be obfuscated behind needing to modify a URL manually.

For release links to either publicly unavailable projects or ones with closed repos, it should be pointing to a raw file on this repo, so long as the file itself is below GitHub's 20MB file limit. If it's just an OPK, then upload that alone; if it's an archive with an OPK plus data files or readme's prepackaged, then the archive should be uploaded in its entirety. It is suggested that you follow the organization and formatting provided on this repo; Games are uploaded to the Games-Ports subdir with an unmodified name (unless necessary), while Emulators are uploaded to the Emulators subdir with the naming format of EmuName_YYYY-MM-DD. When adding to the table, make sure the release link points to the 'raw' data - this can be done by navigating to the file in the repo and clicking on it, and then either right-clicking the raw or download button and clicking Copy Link Location or your browser equivalent. This will ensure that the data automatically begins downloading as soon as the user clicks on the link, so they don't lose their place on the repo.

*Note, when pasting links, you'll want to change the beginning from https://github.com/YourUsername/RetroGame350-AppRepo... to https://github.com/SeongGino/RetroGame350-AppRepo... so that it ultimately points to this master. Even if this isn't done, I'll fix it myself when accepting the PR.

For release links to either publicly unavailable projects or ones with closed repos, if the file is more than 20MB, then the link should point to a file download on your host of choice. Hosted files outside of this repo should be uploaded to a place that you can at least ensure the files will be kept for the indefinite future, to minimize the chances of it mysteriously disappearing due to an invalid account pointer or mindless file deletion. For example, creating a dedicated dummy Google account to host large .OPK packages on its own Drive would be preferred over your own personal Drive. Do not use temporary links; they will be rejected. I can duplicate these to my personal account for hosting in the event the original link is lost, for backup purposes, but don't rely on this as I'm unable to dedicate all of my time to this project in the event you're unable to provide stable hosting.