Moderation Guidelines Reference

Expanded draft reference for moderators covering naming, metadata, image standards, consistency, and future database limitations.

Written By launchbox

Last updated 9 days ago

This article is a working reference for moderators. It expands on the existing Moderation Guidelines draft while keeping the same core principle: all decisions should prioritize consistency, accuracy, and usability for LaunchBox and Big Box users.

Core principle

The Games Database exists to support the best possible experience inside LaunchBox and Big Box. Approve changes that improve accurate imports, useful metadata, clean media downloads, and consistent presentation. Reject or skip changes that reduce trust in the database.


Game naming priority

  1. Use the North American release name if available.

  2. If no North American version exists, use the first English release name.

  3. If no English version exists, use the original release name.

  4. For digital-only Windows titles, use the Steam store name when applicable.


Title formatting

Titles should match official box art or official store listings as closely as possible. Prefer colons when the official title uses a colon. Do not rearrange words for sorting, remove subtitles, or substitute numerals unless the official title does so.


Alternate names

Alternate names are important for LaunchBox import matching. Approve regional title variations, common alternate spellings, and names users are likely to have in their libraries. Use regions where they apply.


Duplicate names on the same platform

The current system has limitations around identical names on the same platform. Moderators should avoid approving manual naming hacks solely to work around that limitation. Long term, duplicate resolution should be handled by metadata and import logic.


Windows and Steam naming

For Windows games, match entries directly to Steam whenever possible. This improves Steam import accuracy and keeps Windows metadata consistent.


Metadata review

Review release dates, game type, publishers, developers, genres, ESRB, max players, cooperative status, overview text, Wikipedia links, video URLs, and alternate names for accuracy. Reject guesses, unrelated links, spammy text, and changes that lack a clear reason.


Image review

Prefer official artwork whenever available. If both physical and digital versions exist, prefer physical box art where appropriate. Maintain consistency across image types and avoid mixing styles or sets within the same category.


Image type enforcement

Some requirements are enforced automatically by the site, including transparent PNG requirements for Clear Logo, Box 3D, Cart, and Disc images; Icon maximum size; Square aspect ratio; and Poster width and aspect ratio. Moderators should still evaluate quality, category fit, and usefulness.


Fanart separation

If an image type does not explicitly support fanart, do not approve fanart in that category. Clear Logos should not be stylized or unofficial logos. Fanart should remain in fanart categories until future tagging provides better separation.


2.5D and 3D media

2.5D and 3D images are most useful as complete, consistent sets. Avoid approving one-off images that create mismatched media groups unless they clearly belong in Reconstructed or Fanart categories and improve the record.


Box spines

For standard cases, prefer one spine image. Use the left spine unless the right spine contains more information. For horizontal formats, use the top spine. For double jewel cases, use a combined image with both spine sections represented evenly.


Release date limitations

The current site supports a single release date or release year on the main edit form. Future systems may support multiple regional, digital, and physical release dates. Until then, use the best broadly applicable value and explain edge cases in the reason.


Rejecting vs skipping

Reject when the proposed change is wrong, low quality, misplaced, unsupported, or harmful to consistency. Skip when you cannot confidently review the submission or need another moderator to look at it.


Writing rejection reasons

Rejection reasons should be specific and useful. Explain what was wrong and, when possible, what the contributor should do differently next time.


Future improvements to keep in mind

Future improvements may include image tagging, better duplicate game support, and expanded release date handling. Moderate based on the current system while avoiding decisions that make those future improvements harder.