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.