====== Article templates and review workflow ======

Approved editors can use these templates in guides, troubleshooting, and community namespaces. Protected command, feature, lobby, and release pages need maintainer review. Start unfamiliar material in ''drafts:your_topic''. Drafts are visible to approved editors and maintainers; they are not private to one contributor.

===== A practical guide =====
<code>
====== Descriptive article title ======

Explain the player's situation and who this guide applies to.

===== Steps =====
  - Give the first action.
  - Explain the expected response.
  - Link to the relevant command or concept.

===== If it does not work =====
Explain restrictions and link to troubleshooting.

===== Verification =====
Checked against: vX.Y.Z on YYYY-MM-DD.
State whether this is current, historical, or an upcoming proposal.
</code>

===== A troubleshooting article =====
Describe the visible symptom first. Separate a command typo, missing permission, a vote without enough agreement, and a server problem. Include a safe example and the expected response. Do not paste raw player logs or private reports.

===== Reviewing behavior =====
  - Verify the supported command and its room restrictions against current behavior.
  - Distinguish the current map, visible queue, and future selections.
  - Identify whether an action is a vote, a preference, or an informational lookup.
  - Mark experimental models and configurable policy accurately.
  - Label staged features as upcoming until deployment is confirmed.
  - Check linked pages and aliases; preview on a narrow screen.
  - Save with an edit summary explaining what changed and why.

There is no automatic approval plugin. Ask a maintainer to review a draft through the existing community channel. Maintainers should preserve revision history and contributor attribution when publishing, and use the actual latest article rather than restoring an old seed copy.

===== Choosing a namespace =====
^ Namespace ^ Intended use ^
| ''guides:'' | Practical player walkthroughs |
| ''troubleshooting:'' | A player symptom and steps to resolve it |
| ''community:'' | Editing and community information |
| ''drafts:'' | Private preparation for approved contributors |
| ''images:'' | Supported media uploaded by approved editors |

Link every published page from a relevant guide or index. Wiki accounts do not grant bot moderator access. See [[community:contributing|contribution rules]], [[community:editor_guide|editing instructions]], and [[wiki:syntax|formatting syntax]].

===== Standard command reference =====
Begin with a one-paragraph definition, then an availability/status/reference table. Use the same headings as [[commands:jack|the Jack command page]]:
  * Usage and examples — valid input, including canonical aliases.
  * Limitations and timing — eligibility, room mode, votes, and when changes take effect.
  * Related articles — concepts, troubleshooting, and worked guides.

===== Standard feature reference =====
Begin with a short summary and the same reference table. Keep the detailed explanatory sections, then add a worked example, limitations, and related articles. See [[wiki:mania_styles|Mania styles]] or [[wiki:queues|queues]].

The behavior reference records a dated source review, not a live-service guarantee. If a contributor changes behavior details without verifying them, mark the status as “Needs review” rather than retaining a misleading verification date. Keep current, upcoming, historical, and experimental claims distinct. A recent edit timestamp alone does not prove current behavior.

===== Diagram conventions =====
Link [[wiki:pattern_atlas|the original pattern diagrams]] where useful. They use time downward, numbered columns, purple taps, and teal holds, with explanatory prose and image descriptions. Do not present an illustrative passage as a classifier acceptance test or a screenshot of an actual map.