Direction Guidelines - Revision history

Vape at 17:39, 7 February 2026

2026-02-07T17:39:51Z

← Older revision		Revision as of 13:39, 7 February 2026
Line 124:		Line 124:

	If, after 10 days without input or a consensus, CR will be considered '''Stalemated''', The final decision to test merge should be made by the head maintainer, or the maintainer handling the PR. Direction may request the content be reverted at a later date after a 14 day test process, and acquiring proper community feedback. <small>This only applies to PR's, and does not apply to design documents.</small>		If, after 10 days without input or a consensus, CR will be considered '''Stalemated''', The final decision to test merge should be made by the head maintainer, or the maintainer handling the PR. Direction may request the content be reverted at a later date after a 14 day test process, and acquiring proper community feedback. <small>This only applies to PR's, and does not apply to design documents.</small>


			== Upstream Merges ==

			Upstream merges are an incredibly complex "update" that is brought into the server from Wizards Den (our upstream). This involves many "refactors" and changes to systems that make our codebase more stable, and able to run more efficiently.

			After each upstream merge, if this contains more than 2 weeks of content, there is a '''Mandatory''' 3 day PR freeze. <small>This may be changed or removed at any time by any head of development</small>

Vape at 16:41, 7 February 2026

2026-02-07T16:41:34Z

← Older revision		Revision as of 12:41, 7 February 2026
Line 1:		Line 1:
			{{DISPLAYTITLE:Content Review Guidelines}}
	{{DISPLAYTITLE:Content Review Guidelines}}		{{DISPLAYTITLE:Content Review Guidelines}}

Vape at 16:41, 7 February 2026

2026-02-07T16:41:07Z

← Older revision		Revision as of 12:41, 7 February 2026
Line 1:		Line 1:
			{{DISPLAYTITLE:Content Review Guidelines}}

	=== Overview ===		=== Overview ===
	This page goes over Content Review, and How to perform these. This goes into detail about CR policy, Design Documents, Content removal, and more.		This page goes over Content Review, and How to perform these. This goes into detail about CR policy, Design Documents, Content removal, and more.

Vape at 16:35, 7 February 2026

2026-02-07T16:35:59Z

← Older revision		Revision as of 12:35, 7 February 2026
Line 109:		Line 109:

	== PR Deadlines ==		== PR Deadlines ==

			Deadlines are required when reviewing new content. Deadlines are relative to the size of the content. The standard method of tracking these deadlines is to create a poll with the appropriate duration in the review post.

			* Small changes are subject to 24 - 48 hours of consideration

			* Major changes are subject of up to 7 days of consideration. <small>this can be extended at any time with approval from a Senior CR or the Content Director</small>

			'''The minimum time for official review is 24 hours.''' <small>This can be shortened at any point with approval from a Senior CR or the Content Director</small>

			CR's should notify authors when the content is placed into official review, and give them an estimated wait time for feedback. If more time is required, the author should be notified.

			If, after 10 days without input or a consensus, CR will be considered '''Stalemated''', The final decision to test merge should be made by the head maintainer, or the maintainer handling the PR. Direction may request the content be reverted at a later date after a 14 day test process, and acquiring proper community feedback. <small>This only applies to PR's, and does not apply to design documents.</small>

Vape at 16:29, 7 February 2026

2026-02-07T16:29:40Z

@@ Line 71: / Line 71: @@
 ==== All content must pass the full review process before being approved ====
 with a few small exceptions. Proposed changes listed below do not require review:
 *Bug fixes
@@ Line 83: / Line 82: @@
 When in doubt, the team should be asked if a review is needed.
-====What to look for in a review====
 *Fits our MRP standard - Keeps the balance between action and roleplay, no overpowered things that break the fun. We want things to make sense in the setting.
 *Fits the Design Ethos - We are a server founded in analogue design. We want this to be displayed in all content that we merge, such that it fits the mechanical narrative of the game.

Vape at 16:24, 7 February 2026

2026-02-07T16:24:53Z

← Older revision		Revision as of 12:24, 7 February 2026
Line 53:		Line 53:

	5. '''Publication''' - At this stage, you will share a “draft” of the design with the public, and collect community feedback. You should use this feedback to flesh out a finalized roadmap for contributors.		5. '''Publication''' - At this stage, you will share a “draft” of the design with the public, and collect community feedback. You should use this feedback to flesh out a finalized roadmap for contributors.


			== Design Documents ==

			Design Documents are a tool for the community to outline and present ideas. Design Documents should use the provided Design Document template.

			The community can create DD prior to opening a PR, and have them reviewed by direction to “fine tune” their ideas to Direction standards before starting development. The Community can also create DD for review without the intention to develop them personally. Contributors can always claim approved documents and begin development themselves.

			Curators can collaboratively create DD to address issues laid out in the roadmap. These documents serve as the “Solution design” step of the roadmap.

			Curators may prioritize certain DD depending on Content Management's needs and goals.

			= Content Review =

			Reviewing suggested content involves examining current Pull Requests (PRs) or Design Documents (DD) and providing feedback. Content review should involve as many members as possible. If only one or two choose to review, their opinion holds the same weight as the entire team. If the rest of the team comes to a different decision at a later date, content can always be reverted.

			==== All content must pass the full review process before being approved ====
			with a few small exceptions. Proposed changes listed below do not require review:


			*Bug fixes

			*Simple tweaks

			*Obvious small changes

			*Additions or changes deemed by the Content Director or Senior CR's to be minor or essential (<small>this includes upstream merges</small>)

			When in doubt, the team should be asked if a review is needed.

			====What to look for in a review====

			*Fits our MRP standard - Keeps the balance between action and roleplay, no overpowered things that break the fun. We want things to make sense in the setting.

			*Fits the Design Ethos - We are a server founded in analogue design. We want this to be displayed in all content that we merge, such that it fits the mechanical narrative of the game.

Vape at 16:20, 7 February 2026

2026-02-07T16:20:05Z

@@ Line 15: / Line 15: @@
-==The Roadmap==
+==Making a Roadmap==
 Developing a roadmap is a multi-step process. Concepts on the roadmap should be selected by the team privately, and the ideas should be established to a level of certainty before being presented for community feedback. Concepts can be specific or broad, as long as they have a “Solid final goal” that the team can guide contributors to. The creation of a roadmap can be broken down in specific steps.
@@ Line 34: / Line 34: @@
 *'''Priority''' - How necessary does the team believe this is? are there external pressures pushing for this?

Vape at 16:18, 7 February 2026

2026-02-07T16:18:05Z

@@ Line 1: / Line 1: @@
 === Overview ===
 This page goes over Content Review, and How to perform these. This goes into detail about CR policy, Design Documents, Content removal, and more.
 == Content Review Policy ==
@@ Line 12: / Line 13: @@
 . Content Reviewers should be reasonably up to date and knowledgeable about the game and its intricacies.

Vape: CR

2026-02-07T16:15:39Z

← Older revision		Revision as of 12:15, 7 February 2026
Line 1:		Line 1:
	=== Overview ===		=== Overview ===
	~~Direction has two branches;~~ Content ~~management~~ and ~~Events~~. This ~~page~~ goes ~~over both~~, ~~as well as the policy on roadmaps~~, ~~events~~, and ~~content management~~.		This page goes over Content Review, and How to perform these. This goes into detail about CR policy, Design Documents, Content removal, and more.

	~~===~~== Content ~~Management~~ Policy ~~===~~==		== Content Review Policy ==
	1. The '''Content ~~Management~~ Team''' is expected to submit a roadmap to the '''~~Game~~ Director''' and '''Project Management''' for review when possible.		1. The '''Content Review Team''' is expected to submit a roadmap to the '''Content Director''' and '''Project Management''' for review when possible.

	2. Content ~~Managers~~ are expected to fulfill their duties without bias. Submission of PR’s that can be considered without merit or otherwise heavily biased, should be considered for denial.		2. Content Reviewers are expected to fulfill their duties without bias. Submission of PR’s that can be considered without merit or otherwise heavily biased, should be considered for denial.

	3. Content ~~Managers~~ are required to have a basic understanding of how PR Submission works, and how to use Github.		3. Content Reviewers are required to have a basic understanding of how PR Submission works, and how to use Github.

	4. In order to vote on a PR, Content ~~Managers~~ must present adequate reasoning and explanations behind their votes.		4. In order to vote on a PR, Content Reviewers must present adequate reasoning and explanations behind their votes. <small>We urge all reviewers to make use of the poll, as well as explain their reasoning.</small>

	5. Content ~~Managers~~ should be reasonably up to date and knowledgeable about the game and its intricacies.		5. Content Reviewers should be reasonably up to date and knowledgeable about the game and its intricacies.

Vape: Content Rework due to new policies

2026-01-28T01:00:43Z

Content Rework due to new policies

Show changes