Direction Guidelines

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

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

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 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 Reviewers must present adequate reasoning and explanations behind their votes. We urge all reviewers to make use of the poll, as well as explain their reasoning.

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

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.

1. Observation & Collection - Observe Discord channels, forums, and in-game interactions. Observing what players are discussing, what they enjoy, and what challenges they face. Monitor dedicated feedback channels, collect suggestions, and identify recurring themes or requests.

2. Conceptualization - after Observing & collecting data, rank Concepts by the following. This is done privately in the #roadmap-development forum.

• Content impact - Is the content aligned with our mission

• Technical Feasibility - What skills are needed for this?

• Breakdown - Break topics down into steps

• Community Interest - Is the community interested in this? Is this something that they would take kindly to?

• Priority - How necessary does the team believe this is? are there external pressures pushing for this?

3. Requirement Gathering - After ranking of Concepts, you should itemize out the following Requirements

• What does this concept seek to do?

• What does this change or add?

• What problems are addressed?

4. Solution Design - This is the stage of turning the “What” from Step 3 into the “How”. For every problem or requirement, break these down into a list of “actionable tasks”. For example, if a requirement is to "create a new player model," a Solution Design task would be "create a specific sprite for the new player model."

• Determine what actions and changes need to be done

• Itemize these into tasks, as small as possible. Are sprites needed? Ask for a specific sprite.

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 (this includes upstream merges)

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.

How to conduct a review

Content Reviews should take place in the #content-review forum channel. The CR who creates a Content Review post assumes responsibility for providing feedback to the author. This includes notifying the author that the content is under review, and summarizing feedback gathered in the review to provide the next steps to the author.

Content Review is not a true vote. Members of CR are encouraged to vote in the poll, give specific feedback on why they support or oppose this content, and what should be changed, all with justification.

Any final decisions must be communicated to the content author through appropriate channels. This will vary between PRs and DD. Design Document (DD) review takes place within Discord. Feedback should be provided within the original DD post in the forum.

Decisions include:
Approval
Approval with priority
Approval with test merge
Requesting changes
Denial

⚠️Maintainers have the final authority when it comes to the fitness of the PR in terms of code quality and bugs or other mechanical concerns.⚠️

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. this can be extended at any time with approval from a Senior CR or the Content Director

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

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. This only applies to PR's, and does not apply to design documents.

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. This may be changed or removed at any time by any head of development