|
|
| (25 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| === Overview & Welcome ===
| | {{DISPLAYTITLE:Content Review Guidelines}} |
| Hello! Welcome to the team, where we professionally wyci things. We’ve got a LOT on our plate, as the pseudo development team sans developers. Below you’ll read about our positions, what we do, and what we don’t do! You will find best practices, what to expect, and how we can do better in the future. This will be an evolving and public document; we strive to work with the people in all capacities.
| | {{DISPLAYTITLE:Content Review Guidelines}} |
|
| |
|
| === '''Important Note!''' === | | === Overview === |
| We know your time is valuable. We'll make sure roadmap plans are clear, easy to understand, and broken down into manageable tasks. You can choose what you want to work on. Your contributions are what make Delta V special, and we appreciate every bit of effort you put in!
| | This page goes over Content Review, and How to perform these. This goes into detail about CR policy, Design Documents, Content removal, and more. |
|
| |
|
| === Code of Conduct ===
| |
|
| |
|
| * Always treat fellow players, staff members, and developers with kindness and consideration. Respect their opinions, even if they differ from your own. Refrain from using offensive language, personal attacks, or any form of discrimination.
| | == Content Review Policy == |
| * Collaborate effectively with others, both OOC and in Discord. Be willing to compromise and work together towards common goals. Support your fellow player and server staff, and always prioritize the well-being of the community as a whole.
| | 1. The '''Content Review Team''' is expected to submit a roadmap to the '''Content Director''' and '''Project Management''' for review when possible. |
| * Maintain an approachable demeanor, encouraging players to reach out and share their thoughts and concerns. Listen actively to others, show empathy, and respond with respect. Foster a positive and inclusive environment where everyone feels comfortable expressing themselves.
| |
| * When participating in discussions, ensure that they remain respectful and constructive. Ask for clarification and purpose when someone posts something vague or unclear. Encourage participants to provide evidence, sources, and examples to support their arguments.
| |
|
| |
|
| === Job Requirements ===
| | 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. |
|
| |
|
| * You understand the intricacies of the game. This knowledge enables you to make informed decisions, solve problems creatively, and lend an expert opinion.
| | 3. Content Reviewers are required to have a basic understanding of how PR Submission works, and how to use Github. |
| * You possess excellent communication skills through writing. You excel at explaining complex concepts clearly and concisely, making it easier for others to understand and engage with the game.
| |
| * You are passionate about the game and appreciate the balance between action-packed moments and immersive roleplay opportunities that Delta V seeks to offer.
| |
| * You are an active member of the Delta V community, regularly contributing to productive discussions.
| |
|
| |
|
| == Content Management ==
| | 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> |
| One of the Direction’s main goals is to oversee the curation of content for the Delta-V community. To accomplish this, Direction operates in a '''Proactive''' and a '''Reactive''' manner. Proactively, they create the Roadmap to indicate what Direction would like to see developed. Reactively, they curate the content submitted to ensure it meets the mission of Delta V.
| |
|
| |
|
| === The Roadmap ===
| | 5. Content Reviewers should be reasonably up to date and knowledgeable about the game and its intricacies. |
|
| |
|
| * The Roadmap operates over a few stages. Concepts on the Roadmap will be selected by the Direction team privately, and the ideas will be established to some level of certainty before being opened to community feedback. Concepts may be highly specific, or rather broad, as long as they have a solid final goal that Direction can guide contributors towards.
| |
|
| |
|
| ==== Discovery ==== | | ==Making a Roadmap== |
| Curators spend time in Discord channels, forums, and in-game, paying attention to what players are discussing, what they enjoy, and what challenges they face. They monitor dedicated feedback channels, collate suggestions, and identify recurring themes or requests. For more details, refer to Community Management
| |
|
| |
|
| ==== Conceptualization ====
| | 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. |
| Through Discovery, rank Concepts by the following metrics. This is done privately in the #roadmap-development forum, with each Concept having the relevant tags as to its status.
| |
|
| |
|
| * Content Impact - Is the content aligned with the Mission of Delta V?
| |
| * Technical Feasibility - What technical skills are needed to complete this project?
| |
| * How can it be broken up into constituent groups?
| |
| * Community Interest - Is the community interested in this specific idea? Is this something they would take kindly to?
| |
| * Direction Priority - How necessary does the direction team believe this is? Are there external pressures pushing for this?
| |
|
| |
|
| ==== Requirement Gathering ====
| | 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. |
| After ranking of Concepts, the Curators should itemize out the following Requirements, with as much detail as possible:
| |
|
| |
|
| * What does this Concept seek to do?
| |
| * What problems does it address?
| |
| * What should it do?
| |
|
| |
|
| === Solution Design ===
| | 2. '''Conceptualization''' - after Observing & collecting data, rank Concepts by the following. This is done privately in the #roadmap-development forum. |
| Curators should then iterate on the Requirements gathered, and develop the Solution Design. For every requirement:
| |
|
| |
|
| * Determine what could be done to resolve this requirement. | | *'''Content impact''' - Is the content aligned with our mission |
| * Itemize these into Tasks, as granular as possible. Are sprites needed? Add a task for a specific sprite.
| |
|
| |
|
| === Publication ===
| | *'''Technical Feasibility''' - What skills are needed for this? |
| At this stage, Direction will share the Solution Design with the public, contained within the global Roadmap. The processes for gathering community feedback are outlined in the Community Management Guidelines. Direction should use this feedback to flesh out Roadmap ideas and finalize them for contributors who wish to begin development.
| |
|
| |
|
| Direction should keep up with the development of these features and offer feedback along the way. Direction guidance ensures that Roadmap content will be developed to the best quality possible and reduce the number of changes that need to be made after the content is presented for official review.
| | *'''Breakdown''' - Break topics down into steps |
|
| |
|
| == GitHub PR Review ==
| | *'''Community Interest''' - Is the community interested in this? Is this something that they would take kindly to? |
| All gameplay content will be processed through the Delta-V Github. Reviewing suggested content involves examining current Pull Requests (“PRs”) and providing feedback through Github.
| |
|
| |
|
| Maintainers have final authority when it comes to the fitness of the PR in terms of code quality and potential bugs or other mechanical concerns.
| | *'''Priority''' - How necessary does the team believe this is? are there external pressures pushing for this? |
|
| |
|
| * Maintainers and Curators will ensure that Direction is reviewing items that fall within the purview of Direction.
| |
| ** We don’t want to review things that our voice is not relevant to! Does it meaningfully affect game design, balance, or roleplay? If not, we can let them know we are not needed to approve it.
| |
| ** Minor bug fixes, obvious simple tweaks, and so forth do not require official review
| |
| * Content review should always involve as many members of Direction as possible, but if only one or two choose to comment on a piece of content, their opinion holds the same weight as the entire team. If the rest of the team comes to a different decision at a later time, '''content can always be reverted.'''
| |
| ** '''What do you look for in a review?'''
| |
| *** Fits our MRP Standard
| |
| **** Keeps the balance between action and roleplay, no overpowered stuff or things that break the fun.We want things to make sense to our setting.
| |
| *** Fits our Design Ethos.
| |
| **** Delta-V is a server founded in analogue design. We want this to be displayed in all the PRs we merge, such that it fits cohesively in the mechanical narrative of the game.
| |
| * Direction may discuss the merits of the content internally, but any final decisions must be communicated to the content author through Github. Typical decisions include:
| |
| ** Approving for merge
| |
| ** Test merging
| |
| ** Requesting changes
| |
| ** Denying the content
| |
|
| |
|
| == Deadlines ==
| | 3. '''Requirement Gathering''' - After ranking of Concepts, you should itemize out the following Requirements |
|
| |
|
| * Directions is a volunteer team. Direction approval is still a requirement for a large portion of new content. In order to prevent bottlenecks and an overall stagnation in new content, deadlines will be enforced for PR Review. | | *'''What does this concept seek to do?''' |
| * Deadlines should be relative to the size of the PR.
| |
| ** Small PRs should be subject to 1-2 days of consideration.
| |
| ** Major PRs may need as many as 1-2 weeks to reach an actionable conclusion.
| |
|
| |
|
| Deadlines should be established relative to whenever the PR is “finalized.” If changes are requested by Direction, the deadline should be extended to the proper amount of time after those changes are implemented by the author.
| | *'''What does this change or add?''' |
|
| |
|
| * '''If Direction does not come to a conclusion by the end of the deadline, the PR is to be automatically merged'''. The intent of this policy is to prevent PRs from sitting unattended for large quantities of time due to Direction inactivity. | | *'''What problems are addressed?''' |
|
| |
|
| == Test Merging ==
| |
|
| |
|
| * Direction’s goal of facilitating change should not be stifled by concerns over the unknown implications of permanently merging any PR. As such, the team is encouraged to temporarily merge PRs whose merits need to be tested. The content can easily be reverted if it is deemed unnecessary.
| | 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." |
| * Test merges should be for short periods of time (24 - 48 hours), and should be supervised by members of Direction to gather information on the quality of the merge. Direction members are authorized to manipulate rounds in accordance with Event Management Guidelines in order to test new content.
| |
| * If Direction members cannot adequately monitor test merges, you may not test merges. A test merge unmonitored provides no actual data for Direction to base decisions on.
| |
| * Additionally in line with Community Management Policy, players should be able to view the current test merges at all times, and be made aware of the general fact that Delta-V uses test merges to analyze content.
| |
| * Some test merge content can be reported on by the community, and feedback can be collected according to Community Management Policy.
| |
|
| |
|
| Community Management
| | *Determine what actions and changes need to be done |
|
| |
|
| Through Community Management, Direction interacts with the community of Delta V. Our mission is done to serve them, and we work to encourage their assistance in upholding this mission. It is our responsibility to act responsibly and with respect.
| | *Itemize these into tasks, as small as possible. Are sprites needed? Ask for a specific sprite. |
|
| |
|
| '''The Voice of the Players''': Curators listen to what players love (and don't love) about Delta V. They:
| |
|
| |
|
| * '''Gather Feedback'''
| | 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. |
| ** Curators actively seek out feedback from players through various channels such as surveys, polls, and direct communication. This feedback is essential for identifying areas of improvement and making informed decisions about the future of Delta V.
| |
| ** '''Recording Feedback''' is just as critical, talk to the team and bring up problem items!
| |
| * '''Solve Problems'''
| |
| ** When players encounter issues or concerns, curators are there to help. They provide guidance, troubleshoot problems, and escalate issues to the appropriate team members for resolution.
| |
| * '''Use Communication Channels'''
| |
| ** '''Announcements'''
| |
| *** The announcements channel is used to share important updates, server news, event information, and roadmap changes. Announcements must be carefully coordinated with the rest of the team to ensure consistency and accuracy.
| |
| ** '''Polls and Surveys'''
| |
| *** Polls and surveys are conducted to gather community feedback on specific topics, gauge interest in potential features, and involve players in decision-making processes. Curators recognize that polls and surveys can also yield uneducated opinions, so they work closely with the team to ensure that questions are clearly worded and unbiased.
| |
| ** '''Public Forums'''
| |
| *** Open forums provide a platform for Direction to speak directly to the community about upcoming changes and get community buy-in for specific ideas. These forums allow for more focused discussions and enable the team to gather valuable insights and feedback.
| |
| ** '''Changelog'''
| |
| *** The in-game changelog can also be used to share important information with players. Many of our players do not use or check Discord, and elaborating on new features, and bug fixes can be helpful.
| |
| ** '''GitHub'''
| |
| *** By leveraging GitHub issues and pull requests, maintainers, contributors, and Curators can collaborate effectively, share ideas, and discuss changes.
| |
|
| |
|
| The roadmap on GitHub plays a crucial role in this communication process. It provides a transparent and accessible overview of the project's goals, priorities, and planned features. By regularly updating the roadmap, Curators can keep contributors informed about where efforts are needed and help align their efforts with the overall mission.
| |
|
| |
|
| == Event Management == | | == Design Documents == |
| '''Events that Rock:''' Curators design exciting in-game events that encourage awesome roleplay. An event is loosely defined as “taking an action that influences the game as an observer”. Spawning in a spider, or working to establish a custom Syndicate objective would be an event! They, by design, are to give opportunities to spice up regular shifts, providing players with unique roleplay scenarios, which they can react to naturally.
| |
|
| |
|
| '''Events must be reported.''' Be robust in your event reporting, especially when giving usually unobtainable items. Be descriptive and attach images or screenshots whenever possible.
| | Design Documents are a tool for the community to outline and present ideas. Design Documents should use the provided Design Document template. |
|
| |
|
| * Unless given '''express permission''' by a Project Manager or the Game Director, do NOT run the following events:
| | 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. |
|
| |
|
| * Non-Natural Zombies, Deathsquad, or Non–evac borne ERT, CBURN etc
| | Curators can collaboratively create DD to address issues laid out in the roadmap. These documents serve as the “Solution design” step of the roadmap. |
| * Administrators may deploy ERT, CBURN, and similar forces in exception of this policy, but only on the evacuation shuttle, and only after request from the station. ''See Event Policy, Medium Impact events.''
| |
|
| |
|
| * '''Events must meet or exceed our MRP Standard'''. LRP, or NRP events such as “wangvasion” have no place outside of Garbage Day/express Head Game Administrator permission.
| | Curators may prioritize certain DD depending on Content Management's needs and goals. |
| * Events are for '''everyone’s''' enjoyment, not just your own.
| |
|
| |
|
| * Do not run events that are designed to interact with one person in particular, especially your own character.
| | = Content Review = |
| * '''Events can and will fail, let them'''. Be it a syndicate dropping event characters dead, bombing or stealing shuttles, command arresting event characters, let it happen.
| |
| * The event should fit within the established lore of the game.
| |
| * Unless your created role has a vital part to the event, let your created ghost roles be taken by someone else, not for yourself. You’re here to provide fun scenarios for players, not for yourself.
| |
| * Do not make ghost roles that are overpowered, or that are intended to be “the protagonist” of the shift. It’s lame to see such things, we want to empower players to tell the story.
| |
| * Feel free to spawn, test things/ideas or doing silly shenanigans in your admin room.
| |
| * Spawning in a bunch of ghost roles to do a gag, build some ship/station, play poker or etc., that generally have NO impact on the current shift, is acceptable.
| |
| * Don’t spawn things that could affect glimmer, make people traitor objectives or some other round ending entities.
| |
| * Remember to be cooperative with other staff! Work, plan together to make certain dumb ideas into functional, fun things!
| |
| * Don’t spawn in a super synth for players. There are some midis that can cause a complete crash.
| |
| * Outside of Events, attempt to influence the round as little as possible.
| |
| * Fellow ghosts might try to pressure you to do something funny! Just remember, you probably shouldn’t, unless it meets our Event Guidelines!
| |
|
| |
|
| '''Events fall into three broad categories, each with different qualifications and actions required. All events must be reported in the #events channel.'''
| | 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. |
|
| |
|
| === Low Impact === | | ==== All content must pass the full review process before being approved ==== |
| | with a few small exceptions. Proposed changes listed below do not require review: |
|
| |
|
| * Events in this category may be at Curator discretion, in moderation. | | *Bug fixes |
| * By nature, they do not impact the round in any meaningful way and potentially could be mistaken as an in-game event, rather than a curator spawned one in.
| |
| ** Curators have leeway to run nigh unlimited amounts of Low Impact events when Glimmer reaches 900+, including some Medium Impact events. Make items sapient, shrink things, make things ''strange.'' Keep your actions within the lore of the game. Feel free to ping the Game Director for additional questions.
| |
|
| |
|
| Examples include:
| | *Simple tweaks |
|
| |
|
| * Responding to certain faxes as CC. | | *Obvious small changes |
| * Making CC announcements regarding non specific advice.
| |
| * Spawning, or modifying a spider during a vent critters event
| |
| * Making something that normally isn't sentient, sentient when the glimmer is abnormally high.
| |
| * Making fun, in-world announcements as non CC about certain things.
| |
| * Answering prayers ( what item was given, if it was actually given).
| |
|
| |
|
| === Medium Impact ===
| | *Additions or changes deemed by the Content Director or Senior CR's to be minor or essential (<small>this includes upstream merges</small>) |
|
| |
|
| * Events in this category may be run at Curator discretion in moderation, but '''should be approved by a Curator first.'''
| | When in doubt, the team should be asked if a review is needed. |
| * Take note to not overwhelm the station! If the round has particularly active traitors, don’t make it worse for Security!
| |
| * Medium Impact events may interfere with the crew, but should generally not provide the opportunity to derail the station, or round remove players.
| |
| * Medium Impact events should be '''planned out in advance'''. Write out an event plan, with requirements, objectives, goals, etc.
| |
|
| |
|
| === High Impact ===
| |
|
| |
|
| * Provide at least a 4 hour notice before it starts. Additionally, notify the Patreon Event Notifications channel.
| |
| * The type of round will heavily influence the feasibility of this category of event. You may have to force extended or survival in the pre-round lobby.
| |
| * Use “setgamepreset” to do so. Once the round has started, run “setgamepreset secret” to fix it for future rounds.
| |
| * High Impact events WILL interfere with the crew, and '''must be planned in advance'''. '''Write out an event plan, with requirements, objectives, goals, etc.'''
| |
| * High Impact events should be carefully examined to ensure they meet or exceed our MRP standards.
| |
|
| |
|
| '''Do not run these events solo.''' You should be working together with a team of Curators(at least 2-3 minimum). Ask for help in #events, or ping @Curator
| | ==What to look for in a review== |
|
| |
|
| Examples include:
| | *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. |
|
| |
|
| * Hellshift | | *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. |
| * Rimworld Events | | |
| * AI Malfunction | | |
| * Central Command Inspections
| | ==How to conduct a review== |
| * Furtive Fugitives - dV Event Plan
| | |
| | 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. <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> |
| | |
| | |
| | == 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> |
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:
- 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
