|
|
| (10 intermediate revisions by 2 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. 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.
| |
|
| |
|
| === 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''' - 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''' - 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.
| | ==Making a Roadmap== |
|
| |
|
| * Content Impact - Is the content aligned with the Mission of Delta V?
| | 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. |
| * 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''' - 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?
| | 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. |
| * What problems does it address?
| |
| * What should it do?
| |
|
| |
|
| '''Solution Design''' - 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.
| | 2. '''Conceptualization''' - after Observing & collecting data, rank Concepts by the following. This is done privately in the #roadmap-development forum. |
| * Itemize these into Tasks, as granular as possible. Are sprites needed? Add a task for a specific sprite.
| |
|
| |
|
| '''Publication''' - 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. | | *'''Content impact''' - Is the content aligned with our mission |
|
| |
|
| === Design Documents ===
| | *'''Technical Feasibility''' - What skills are needed for this? |
| Design Documents are a tool for Curators and Contributors alike. Design documents are a standardized method of outlining and presenting ideas. It is recommended to use the provided [[Design Document Template]] for the sake of consistency. Document templates and the relevant channels can be found in the Discord development category.
| |
|
| |
|
| Contributors can create Design Documents prior to opening a PR, and have them reviewed by Direction in order to tune their ideas to Direction standards before starting the development process. Contributors are also welcome to create Design Documents for review without the intention to develop them personally. Other contributors can always claim approved documents and begin development themselves!
| | *'''Breakdown''' - Break topics down into steps |
|
| |
|
| Curators can collaboratively create Design Documents to address issues laid out in the roadmap. These documents serve as the “Solution Design” step of the roadmap, and will be available to contributors who wish to develop them.
| | *'''Community Interest''' - Is the community interested in this? Is this something that they would take kindly to? |
|
| |
|
| Curators may designate design documents with varying levels of priority according to how pressing Direction finds the issue.
| | *'''Priority''' - How necessary does the team believe this is? are there external pressures pushing for this? |
|
| |
|
| === Content Review ===
| |
| Reviewing suggested content involves examining current Pull Requests (“PRs”) or Design Documents and providing feedback. Content review should always involve as many members of Direction as possible, but if only one or two choose to review 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.
| |
|
| |
|
| '''All content must pass the full review process before being approved''', with a few small exceptions. Proposed changes for the following do not require a Direction review: | | 3. '''Requirement Gathering''' - After ranking of Concepts, you should itemize out the following Requirements |
|
| |
|
| * Bug fixes | | *'''What does this concept seek to do?''' |
| * Simple tweaks
| |
| * Obvious small changes
| |
| When in doubt, the Direction team should be asked if a review is needed.
| |
|
| |
|
| ==== '''What do you look for in a review?''' ====
| | *'''What does this change or add?''' |
| * 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.
| |
|
| |
|
| ==== How is a review conducted? ====
| | *'''What problems are addressed?''' |
| Content review takes place in the #content-review forum channel in the server Discord. The curator 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 post to provide next steps to the author.'''
| |
|
| |
|
| If a curator is the author of the content, '''they should find another curator to assume responsibility for review of the content'''. <u>Curators should not argue in favor of their own suggested content in posts</u>, in order to ensure it stands on its own merit. Content collaboratively designed by Direction is exempt from this restriction.
| |
|
| |
|
| '''<u>Content review is not a vote</u>'''. Polls are not to be used for anything except timing purposes. Members of Direction are encouraged to give specific feedback on why they support proposed content or what they think should be changed about it, with justification. It is the review post author’s responsibility to summarize this concisely for the content author. | | 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." |
|
| |
|
| After Direction has discussed the merits of proposed content internally, any final decisions must be communicated to the content author through appropriate channels. This will vary depending on whether the content is a Design Document or a PR.
| | *Determine what actions and changes need to be done |
|
| |
|
| '''Design Document''' review takes place entirely within the Discord. Feedback will be provided to the author through the Discord. Typical decisions include:
| | *Itemize these into tasks, as small as possible. Are sprites needed? Ask for a specific sprite. |
|
| |
|
| * Approving the document
| |
| * Approving with an elevated priority tag
| |
| * Requesting changes
| |
| * Denying the Document
| |
|
| |
|
| For '''Pull Requests''', feedback should be communicated to the author through Github. Typical decisions include:
| | 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. |
|
| |
|
| * Merging the PR
| |
| * Test merging the PR
| |
| * Requesting changes
| |
| * Closing (Denying) the PR
| |
|
| |
|
| '''<u>Note:</u>''' 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.
| | == Design Documents == |
|
| |
|
| === Deadlines ===
| | Design Documents are a tool for the community to outline and present ideas. Design Documents should use the provided Design Document template. |
| 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 Content Review. Deadlines should be relative to the size of the content. The standard method of tracking a deadline is to create a poll of the appropriate time frame in the review post.
| |
|
| |
|
| * Small changes should be subject to 1-2 days of consideration.
| | 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. |
| * Major changes may need as many as 1-2 weeks to reach an actionable conclusion.
| |
| * The minimum amount of time for a review is 24 hours.
| |
| Curators should notify content authors when their content is under official review, and give them an estimated wait time for feedback. If more review time is required, the author should be notified before the previously stated review period ends.
| |
|
| |
|
| Deadlines should be established relative to whenever the content 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.
| | Curators can collaboratively create DD to address issues laid out in the roadmap. These documents serve as the “Solution design” step of the roadmap. |
|
| |
|
| If, after sufficient requests for input, Direction '''consistently''' fails to provide feedback on a PR, <u>the final decision to approve or deny can be made by the Head Maintaine</u>r. Direction may request the content be reverted later if need be.
| | Curators may prioritize certain DD depending on Content Management's needs and goals. |
|
| |
|
| === Content Removal ===
| | = Content Review = |
| Some currently implemented content will inevitably have to be replaced or removed in order to achieve Direction’s design vision. Direction’s preference should be to replace content that doesn’t meet our standards with improved content where possible.
| |
|
| |
|
| In order to remove content, Direction must complete each of these steps:
| | 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. |
|
| |
|
| * Make a list of quantified issues with the content.
| | ==== All content must pass the full review process before being approved ==== |
| * Create a design document that addresses these issues. If Direction cannot do this, it should be stated on the issue page.
| | with a few small exceptions. Proposed changes listed below do not require review: |
| * Present the issues and design solutions to the community in the Github.
| |
| * Establish a deadline for action to be taken.
| |
|
| |
|
| If no action has been taken by the deadline, the content will be removed. Appropriate deadlines are as follows. Content examples are not comprehensive.
| | *Bug fixes |
|
| |
|
| * 1 week: Minor content (sprites, mechanical balance of an item, etc.). | | *Simple tweaks |
| * 2 weeks: Moderate content (roles, machines, etc.).
| |
| * 1 month: Major content (gamemodes, etc.).
| |
|
| |
|
| Content that is extremely broken or clearly and severely detrimental to the game experience may be removed without this process. Content may be removed upon the original creators request without navigating these processes.
| | *Obvious small changes |
|
| |
|
| === Test Merging ===
| | *Additions or changes deemed by the Content Director or Senior CR's to be minor or essential (<small>this includes upstream merges</small>) |
| Tmerges may be conducted on PRs whose effects are potentially unclear. A test merge consists of merging content that may be pending changes, or reversion. The purpose of the merge is to gather feedback from an in-game scenario in order to make such decisions. Test merges may be conducted on a test server if appropriate.
| |
|
| |
|
| Players should be made aware of all active test merges on their current server.
| | When in doubt, the team should be asked if a review is needed. |
|
| |
|
| Curators are authorized to manipulate rounds in accordance with Event Management policies in order to test said content.
| |
|
| |
|
| Test merges must be monitored, or otherwise have an official way of collecting community feedback (such as a feedback forum). If there are specific aspects of the content that Direction is looking for feedback on, this should be made known to the community before the test. Otherwise, a test may be used to discover previously unknown issues with the content, but '''Direction should take care to ensure content is in the best state possible before conducting a test merge'''.
| |
|
| |
|
| == Community Management == | | ==What to look for in a review== |
| 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. Curators listen to what players love (and don't love) about Delta V. They:
| |
|
| |
|
| '''Gather Feedback -''' 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!
| | *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. |
|
| |
|
| '''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.
| | *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. |
|
| |
|
| '''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.
| | ==How to conduct a review== |
| * '''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.
| | 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. |
|
| |
|
| == Event Management ==
| | 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. |
| Events are a term used to describe any action taken by a member of staff that influences the affairs and happenings aboard the station. The goal of an event is to supplement and enhance existing situations, create unique scenarios that players can choose to react to, or to resolve situations in a non-administrative capacity. Spawning items and mobs, setting custom objectives, and granting requests would each constitute events, while actions like banning a player or answering a CHelp would not.
| |
|
| |
|
| ==== Event Rules and Best Practices ====
| | 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. |
|
| |
|
| * '''Events must be reported.''' Event reporting serves to show the actions staff made during the round; be thorough and include all relevant details (including, but not limited to: rationale behind the event, items spawned, players affected), as well as screenshots where possible.
| | Decisions include: |
| * '''Events should be allowed to play out at their own pace.''' Events will almost invariably be affected by the crew, antagonists, or natural occurrences within the round; let the round flow organically and allow players to interact with the event rather than forcing them to follow a script.
| | Approval |
| * '''Events must meet or exceed our MRP Standard.''' Both the rationale and implementation of an event must demonstrate evidence of conscientious design; do not run events due to boredom, for primarily humorous purposes, or just to interfere with characters or the round as a whole.
| | Approval with priority |
| * '''Events must not feature staff-level ghostroles such as deathsquad, CBRN, etc.''' unless directly authorised by a Project Manager or a Game Director. These roles should be filled by staff and represent both administration and curation in an in-character fashion. Abuse of these ghostroles tarnishes the reputation of staff and will result in demotion or suspension.
| | Approval with test merge |
| * '''Events should fit within the established lore of DeltaV'''; additionally, limit elaborate events revolving around original characters and organisations.
| | Requesting changes |
| * '''Events should never portray NanoTrasen or Central Command as directly antagonistic to the crew.''' While Central Command is expected to be strict - especially on matters of policy and procedure - they should be supportive where possible, politely evasive when pressed, and only authoritative in extreme circumstances.
| | Denial |
| * '''Event roles should be reserved for players.''' Staff are expected to organise and oversee the event, not partake in it.
| |
| * '''Events should not disrupt the balance of the round by introducing overpowered, unique, or usually unobtainable ghostroles, entities, or items.''' This includes objective items, spawn-only items, leviathings, etc.
| |
| * '''Events should not overwhelm the round or the station and its resources.''' Be sure to check the current round and gamemode before running an event and evaluate the effect that the event may have on the various departments and personnel.
| |
| * '''Events should not be biased towards or against specific player(s).''' The capability to run events is a privilege provided to allow staff to improve the round as a whole, not to provide entertainment for metafriends or popular players.
| |
| * '''Events should have a meaningful impact on the round or to players.''' They should be designed, where possible, to affect multiple players, departments, or the station as a whole. Events that are isolated from the station and without significant effect on the round should be avoided.
| |
|
| |
|
| ==== Event Categories ====
| | ⚠️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.⚠️ |
| Events can be divided into three categories, each of which must be recorded in the event log.
| |
|
| |
|
| ===== '''1. Low Impact''' ===== | | == PR Deadlines == |
| These events may be run by Game Administrators, Trial Curators, and Curators without approval.
| |
|
| |
|
| Low Impact events either:
| | 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. |
|
| |
|
| * Do not impact players in any meaningful way and should be easily mistakable for an in-game event, or | | * Small changes are subject to 24 - 48 hours of consideration |
| * Are a direct response to any player request or interaction, and do not affect the round to a great degree.
| |
|
| |
|
| Examples of Low Impact events include:
| | * 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> |
|
| |
|
| * Spawning a single spider in a maintenance tunnel.
| | '''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> |
| * Sending the station a replacement board for a machine or computer.
| |
| * Acknowledging a prayer by flashing the player and spawning ash.
| |
|
| |
|
| ===== '''2. Medium Impact''' =====
| | 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. |
| These events may be run at Direction’s discretion ''when approved by a Curator''. <u>Ping Event Managers prior to running these events.</u>
| |
|
| |
|
| Medium Impact events:
| | 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> |
|
| |
|
| * Considerably affect players or the round without derailing the round, round-removing players, or taking significant resources and manpower from departments, or
| |
| * Add a new gamerule unlikely to cause significant effect on players or the round,
| |
| * Are a direct response to an in-character player request or interaction that affects the round by noticeably altering its course.
| |
|
| |
|
| ''For easier access and review by curators and yourself, and to better repeat such events, it is heavily advised to write down the event and its details in Direction’s event library. Events planned in advance and approved by Curators may be run at the discretion of Trial Curators.''
| | == Upstream Merges == |
|
| |
|
| Examples of Medium Impact Events include:
| | 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. |
|
| |
|
| * Selling a shuttle to the station containing minimal equipment.
| | 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> |
| * Sending a member of Central Command, played by a member of staff, to the station.
| |
| * Providing a custom objective to an antagonist on request.
| |
| | |
| ===== '''3. High Impact''' =====
| |
| These events may be run ''following the mandatory notice'' and ''when approved by a Curator''. <u>Ping Event Managers prior to running these events.</u>
| |
| | |
| High Impact events:
| |
| | |
| * Heavily affect players or the round, possibly derailing the round, round-removing players, or taking significant resources and manpower from departments, or
| |
| * Add a new gamemode, causing significant effect on players or the round,
| |
| * Are a direct response to an in-character player request or interaction that results in a Medium or High Impact event.
| |
| | |
| ''⚠ High Impact events must be planned, written in Direction’s Event Library, and approved by a Curator. Additionally, a mandatory four hour notice must be posted in the event log prior to running these events, unless otherwise authorised by a Game Director or Project Manager. An event plan should include entity/role requirements, event goals, players and departments involved, et cetera.''
| |
| | |
| ''If possible, try to involve as many departments as you can. Having an event dedicated towards only one or two departments does not make it fun for the rest of the players.''
| |
| | |
| ''⚠ '''Do not run these events solo.''' Collaborate with at least another two Curators and ask for help in Direction or the event log channel. Make sure that administrators are aware of and overseeing High Impact events.''
| |
| | |
| Examples of High Impact Events include:
| |
| | |
| * Sending an ERT independent of the evacuation shuttle.
| |
| * Setting up a scheduled wedding between two players.
| |
| * Providing a custom objective to an antagonist on request.
| |
| | |
| ==== Event Exceptions ====
| |
| Staff are permitted to spawn in admin/curator characters at Central Command for the purpose of greeting arriving crew on evac, writing faxes, etc. but must enter an entry into the event log. Faxes, announcements, and other interactions with the station are still subject to event categorisation and according requirements for approval.
| |
| | |
| | |
| Staff are permitted to create Ghost Bars (spawning in ghost roles on a separate map from the station for the purpose of a gag, sandbox construction, et cetera) but must enter an entry in the event log.
| |
| | |
| * Ghost Bars should have no interaction with or impact on the round and its players.
| |
| ** Do not spawn round ending entities, entities that can affect glimmer, or entities that may cause issues with traitor objectives.
| |
| | |
| | |
| Staff are permitted to spawn Emergency Response Teams (ERT) on evacuation shuttles with a corresponding entry into the event log under the following circumstances:
| |
| | |
| * The station has been at an elevated alert level (Condition Red or higher) for a period of ten minutes or longer, and there are current active threats aboard the station.
| |
| * The station’s Command Department has sent a request via fax, announcement, or red phone for ERT to be deployed on evacuation or at the earliest possible convenience.
| |
| * The evacuation shuttle was required to be called by a curator or administrator and there are current active threats aboard the station.
| |
| | |
| Additionally, the use of an Emergency Response Team is held to the following standards:
| |
| | |
| * ERT roles should only be offered to players with adequate playtime and relatively clean records.
| |
| | |
| * ERT should always prioritise the safety of the crew first, then assets aboard the station, then enforcement of procedure and policy.
| |
| * ERT should always be supervised by a Leader or Central Command official played by a member of staff.
| |
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
