Direction Guidelines

Under Construction This policy is currently under construction. All current documents are subject to change.

Interim CR Conduct Policy

This document outlines the responsibilities of members of the Interim Content Review Team (Interim CR) in terms of behavior while conducting Interim CR business or acting in a private or public-facing capacity for Interim CR-related subjects. The Interim CR Conduct Policy may be temporarily suspended or bypassed by a majority vote of High Command as specified in the High Command Voting Policy. Any staff member engaging in the content review process (A.K.A. Reviewers) is beholden to this policy, including but not limited to: Interim Reviewers, Heads of Staff, Project Managers, and Maintainers. Any PR author is also subject to these policies when interacting with Reviewers. If this policy is broken by a PR author, this can result in a denial of the PR, a suspension of access, or removal from the codebase.

Approach to Content Review

1. Reviewers are expected to approach the process of content review with awareness of any personal biases regarding relevant subjects to the review, and should make those biases known to other Reviewers.
2. Reviewers should, even acknowledging biases, endeavor to approach the process of content review in an objective manner, and with the goal of achieving constructive dialogue and consensus (if possible) on the PR being reviewed.
3. Reviewers should utilize the Content Review bot (the "Raised Issue" system) and should have a generalized understanding of how the system functions and its appropriate use.
4. Reviewers should have a basic understanding of how PR submission works, including basic GitHub operations (pull requests, merges, etc), and should be reasonably up to date on the current state of Space Station 14 (the game, its mechanics, how systems function in play, etc).
5. Reviewers should focus on discrete issues when conducting content review, rather than making generalized statements ("I don't vibe with this," "This PR doesn't feel right," etc).
6. Reviewers should read the PR, ask questions of other reviewers or the PR author if necessary, and develop and articulate a stance on the PR.

Behavior & Conflict of Interest

1. Staff cannot act as Reviewers for their own PRs. This includes but is not limited to: voting in favor of the PR, triaging the PR, or finalizing reviews of their own PR. Staff who are PR Authors are permitted to advocate, represent, clarify, and generally engage in conversation with Reviewers, as is normal for PR Authors; however, extended lawyering or attempts to use "soft power" (influence due to staff position, etc) can result in the Staff PR Author's access to the discussion being limited or denied, or the PR being denied by the Interm CR Team.
2. Bullying, toxic statements, condescension, or "talking down" to others by Reviewers is not allowed. This applies to Community Members, PR Authors, or other Reviewers. If Reviewers engage in any of the above behavior, or violate the Staff Policy in the course of Interim CR work, they may have access to the discussion restricted or denied by the Interim CR Head or Moderation Staff. Repeated instances of the above behavior may lead to removal from the Interim CR Team at the discretion of High Command (as outlined in the Head Staff Voting Policy).
3. Reviewers are encouraged to employ their expertise in discussion, but also to respect the expertise of other Reviewers in turn. Attempts to "correct" or otherwise dismiss the arguments of others in an offhand manner (i.e., one not backed by evidence/explanation) may be considered toxic behavior and may result in consequences as outlined above.

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 Interim Team lead 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 either the #public-content-review or the #private-content-review forum channels. The Senior Content Reviewer 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 vote. Content Review's take place with a raised issue system. If you have an issue with something in the PR, you should raise an issue using the Content Review bot using the small guide below:

1. Send a message outlining your issue with the PR.
2. Hover over the message.
3. Hover over Apps.
4. Hover over Delta-V Bot.
5. Click on Raise Issue. The message you send will be pinned and viewable by entering the command /cr issue overview. With every reminder message sent by the bot, the ratio of issues and overrules will be displayed. The same way is done to overrule issues.

If an issue is not addressed, it must wait until the end of a review period. At the end of a review, the Senior Content Reviewer who initiated review, will tally both issues and overrides, and then determine whether the issues will prevent a PR from being merged. This includes requesting changes, applying a test merge, approving the PR as is, or denying the PR. This can be overridden by the Content Director at any time.

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 (IE Head Mapper, Head Maintainer)