Language…
22 users online: Anorakun, ASMagician Maks,  Atari2.0,  E-man38, Gasterus155, Ice Man,  Lazy, Minish Yoshi, MisterLV64,  Nanako,  NopeContest, Pat_s2, Rykon-V73,  Segment1Zone2,  Teows, thatwaterblockrk, TheMorganah, TheOrangeToad, TheSpreee333, Ultramegagigantor, zAce08xZ, Zavok - Guests: 138 - Bots: 119
Users: 67,937 (2,098 active)
Latest user: LebdTima

Submission Guidelines

The pages here detail all of SMW Central's submission guidelines for all resource sections and for submitting hacks. They contain information on quality expectations and important points regarding the site's core values.

Update Policy

Update Policy

The following are guidelines for updating hacks or resources as part of the moderation process, or if you are seeking to update or fix an existing moderated resource.

All Updateslink

The following guidelines are required when making update submissions to any resource or hack.

  • Make detailed submission notes
    The submission notes of an update should detail all changes have been made so that section moderators can look for those changes during moderation. If the field for submission notes is too restrictive feel free to include a detailed update log as a plaintext file with the submission.

  • Keep a changelog in the description
    Write a brief note about the changes made in the description of the hack or resource that lets users known what was changed from the previous version, either with the date or a version number. e.g. "YourUsername: Fixed free RAM issue on SA-1 (YYYY/MM/DD)"

  • Avoid Frequent Update Submissions
    It is understandable to want to fix issues in your hack or resource, however with the limited resources of the moderation team frequent updates to fix issues may lead to your submission having lower priority in the queue over newer ones. It is recommended that as many changes as possible are made between updates before you make a submission.


Updating Un-moderated Submissionslink

If you are seeking to update your hack or resource after it has been claimed for moderation, or while it is still in the queue waiting to be moderated, follow these points of advice.

  • Updating an Unclaimed Submission
    While a hack or resource is unclaimed—i.e. no section staff have claimed it for moderation—and still the waiting queue, you are free to update it as often as you like before it has been claimed. If you are making frequent updates while your submission is in waiting, let the moderation team know you are doing this so it can remain unclaimed until you are finished (also let them know you are done).

  • Updating a Claimed Submission
    If you would like to update your hack or resource but a moderator has claimed it, send a message to that moderator about what you would like to update and be specific about what changes you would like to make. A moderator may then make a determination about whether to continue with the current moderation or release the resource or hack for updates.

It is recommended that you let the moderation process complete and then submit a follow-up if necessary, to avoid wasting the time of the moderation team. In the case of some resource submissions, a moderator may reach out to help resolve very minor issues in a submission to help get it into an acceptable state.

Hack-specific Guidelines

Unlike resources, hacks have some extra considerations to be aware of because of the effort involved to moderate them.

  • Avoid major updates to a claimed hack
    If your changes to a claimed hack are sufficient to trigger a re-moderation it is suggested that you hold off on making those changes so that an initial moderation of your hack can be completed. Changes to multiple levels or big content changes, opposed to minor bug fixes, are the sorts of things that would trigger a re-moderation since those levels would have to be replayed. Waiting to make the desired changes in a larger update that comes later avoids wasting the work of the moderator who first claimed your hack.

  • Keep updates to a reasonable amount
    We recognize that hacks are a labour of love that may need attending to with updates, but every update to an accepted hack triggers a full re-moderation regardless of what was changed and since the moderation policy requires that any submission is fully playable as-submitted, so it must be fully replayed to ensure that. Therefore, it is strongly suggested that updates to an accepted hack be reasonably spread out and bundle as many fixes as possible into each of those updates; avoid making frequent minor updates after the first acceptance of your hack.



Re-submitting After Rejectionlink

Rejection is not the ultimate fate for your resource or hack, usually the causes of rejections are quite fixable and moderators will mention those in a moderation log and it will be up to you if you decide to fix those issues and re-submit. However, if a submission is of too poor quality to be fixed, or is unsalvageable, that will also be mentioned and you will be prohibited from re-submitting.

  • Fix all issues mentioned in a log before re-submitting
    In the event of a rejection, a moderator will point out fixable issues, failure to address all of issues that were pointed out in a rejection log will result in getting rejected a second time since the issues will still be present. Repeatedly disregarding moderation feedback may result in you being banned from submitting to that section either temporarily or permanently.

  • Reach out to staff about rejection concerns
    Sometimes the moderation team makes mistakes or you may want to appeal the reason for a moderation, feel free to reach out to the moderators or to a team manager about a moderation decision if you need help, have concerns or need clarification.

  • People are around to help fix your submission
    If you need help following up on an issue in a rejection log, reach out to staff or in the Discord about getting your issues fixed so you can get your submission into an acceptable state.



Updating Moderated Resourceslink

Sometimes bugs or issues are discovered in a resource on the site after they have been published. As per Rule C1 of the Site Terms, any user in good standing is free to submit updates to any resource that fix any issues found in them and the following guidelines cover what is or is not permissible when doing so.

  • Fixing performance or compatibility issues
    The moderation process isn't perfect and sometimes issues slip through. Any performance bugs or issues with compatibility that are discovered in a resource can be fixed and submitted as an update to any resource. This does not apply to Music resources or hacks which may have imperfections that are intentional.

    • Performance bugs are any minor issues that are discovered in a resource that impacts its efficacy or usability as a resource—how it performs as a resource for users.
    • Resources may also be updated to improve their compatibility with newer emulators, newer tools, or to work nicely with other standard resources.

  • Updating a description or missing metadata
    A direct update isn't required for this and you can simply reach out to someone on the relevant moderation team to fix a description or missing metadata. But try and keep requests like that to a minimum as to not make the task of doing so burdensome.

  • Updating hacks tagged "FIXME"
    Some hacks have known compatibility issues on modern emulators, which will be listed in the description of the hack and the hack will be tagged fixme. You are free to submit updates to tagged hacks to fix those listed, and only those hacks, otherwise only the original author can update their hack.

  • Adding features to resources
    You cannot send an update to a resource that builds upon it or add new features without the explicit permission of the original author. However, if the author is significantly inactive (details below) you are permitted to do so, otherwise if an author's activity is unclear you can check with the moderation team about making an update of that nature.


Account Activity & Updateslink

Rule C1 of the Site Terms outlines inactive accounts as those who have not logged into the site in the past six months, this time frame should be the followed for considering a resource "abandoned" before considering making big updates to it or taking it over as a maintainer. However, there are exceptions that could be made if the inactivity of a user is known, they are hard to reach, or they are inactive as the maintainer of a given resource despite logging into the site periodically. In those cases, there isn't a concrete way to say a user inactive so reach out to the relevant moderation team about the update(s) you would like to make so a decision can be made.

When you can take co-authorship

In updating an existing resource authored by someone else you may do significant work to improve it, at which point you can add yourself to the list of authors on said resource if:

  • You are taking over the maintenance of a resource from another author who is disinterested and granted you permission or who is inactive.
  • Your fixes substantially alter a resource's code/material such that a significant part of the resource has now been authored by you.
  • You are building on an existing resource to add more features and further its development, with requisite permissions.
  • You have done your best to seek the original author's blessing to build on their work if they are an active user.

Additionally, minor fixes do not grant you co-authorship status and you cannot remove the original author(s) from a resource when making an update.