Before You Post

This guide explains how to write clear, useful suggestions in the SFMB #request channel. The [[sfmb_betatest_community_rules]]{Community Rules} still apply and take precedence over this guide.

Use #request when you want to suggest a new feature, object, option, or intentional change to existing behavior. If SFMB currently behaves incorrectly, crashes, or produces an unexpected result, use #bug and follow the [[sfmb_bug_reporting_guide]]{Bug Reporting Guide} instead.

Who Can Post

You must hold at least one Special Role to post in #request. See [[sfmb_community_roles/#special-roles]]{Community Roles — Special Roles} for the current roles and requirements.

Check for Existing Requests

Search #request and check the [[sfmb_roadmap]]{Roadmap} before posting so that you know whether the idea has already been discussed.

You may post a request that has already been requested when you want to emphasize continued interest in the idea. When possible, reference the earlier request and add current, clearer, or otherwise useful context. Every repeated request must still follow the complete request format. Do not flood the channel with the same request repeatedly.

Do not ping the Developer just to get attention, pressure staff for a decision, or use the Developer's status reactions yourself.

What Makes a Useful Request

A useful request follows the official five-item format:

  1. The element you want to add to the game. Name the requested element or feature clearly.
  2. An explanation of the element. Explain how it works and what it looks like. Images or footage may be included.
  3. Its origin. State where it first appeared in the series. Use None or Original when it has no existing origin.
  4. The reason you want it in SFMB. Explain why it would improve the game or help players and creators.
  5. How it will work in SFMB. Describe its in-game behavior, Map Editor behavior, options, and important interactions.

References, edge cases, related Roadmap items, and comparisons with the current SFMB behavior are useful optional additions, but they do not replace the official five items.

Scope and Clarity

Keep one main idea per request. Closely related options may stay together, but unrelated objects or features should be separate requests so that each can be reviewed independently.

Be specific without prescribing unnecessary implementation details. Describe the visible behavior and desired result. The Developer decides whether, when, and how an accepted idea is implemented.

Avoid vague requests such as “add more enemies” or “make the editor better.” Name the feature, explain its behavior, and state why it would improve SFMB.

Weak:

Add more Koopa options.

Better:

Add a Map Editor option that makes a Koopa turn around at platform edges. The option would help creators reproduce enemy behavior used in later Mario games without building extra walls around a platform.

Request Template

This copyable template follows the official format in the Community Rules. Replace each prompt.

1. Element to add to the game:

2. Explanation of the element:

3. Origin:

4. Reason for adding it to SFMB:

5. How it will work in SFMB:

You may add reference images or videos, a related existing request or Roadmap item, the current SFMB behavior, and optional enhancements after the five required items.

After Posting

The Developer uses status reactions to indicate that a request was accepted, denied, is already on the Roadmap, needs clarification, is under development, or is complete. Moderators may reject requests that do not follow the required format or are otherwise unsuitable for the channel. Do not add these status reactions yourself.

Acceptance is not a promise of a release date. Do not repeatedly ask when an accepted request will be implemented. If clarification is requested, respond with the missing information clearly and concisely.

For a small correction or clearer example, edit the original request or add one concise follow-up. You may create a new duplicate request later to emphasize the idea again, but it must use the complete format and must not become spam.

Final Checklist

Before sending a request, confirm that:

  • You have permission to post in #request.
  • If the idea was posted before, repeating it is intentional and not spam.
  • It contains one independently reviewable idea.
  • The requested feature or change is named clearly.
  • Its origin and original behavior are described when applicable.
  • Its expected SFMB and Map Editor behavior are explained.
  • The reason it would improve SFMB is specific.
  • Links and reference files are accessible.
  • The whole request is readable as one organized message.

Related Documents

  • [[sfmb_betatest_community_rules]]{Community Rules}
  • [[sfmb_bug_reporting_guide]]{Bug Reporting Guide}
  • [[sfmb_community_roles]]{Community Roles}
  • [[sfmb_roadmap]]{Roadmap}