Reviewing Content With Ethos

_{This goes over how to review content that has been submitted to the github with ethos. This lays out the policy for how to conduct such reviews, as well as the "Checks and Balances" of reviews.}

Ethos Policy

1. CR's will review all content against the expectations of Ethos. Minimal effort reviews such as "I don't like this" or reviews that hold little regard for our current vision and outline will Not be taken into consideration.

2. CR's are expected to be well versed in the specific Ethos category when placing a review of the same category. For example, If a medical PR is made, You should be well versed in the Ethos of medical PRIOR to posting a review

3. Reviews can and should be made against ethos when it is in the best interest of the community, or content. If a reviewer is going against the ethos, then the review must be well structured, and list out the reasons why as well as the laying out a consideration for if Ethos should be changed, or if this is a "one-off case". If a reviewer makes a low effort review going against ethos, it will not be considered.

4. If a PR is voted by CR to bypass Ethos, a mandatory test period of 14 days is to take place Project Managers will be informed of the Bypass via a ping, and will work with Administration and Events to ensure that this content is adequately tested. A community feedback channel will be created, a community poll will be created at the 10 day mark, and will run for 3 days. On the 14th day, Project Management in Tandem with Content Review will examine the test period, as well as submit any proposals to change Ethos as needed.

5. Reviews placed at any time that are derogatory or insulting to the creator and/or content of the PR will not be considered.

6. Reviewers are expected to propose changes to Ethos regularly. Ethos should be ever-evolving with the community, and should not stagnate. If Reviewers fail to submit proposed changes to Ethos, Any Head of staff, Including Project Managers, can announce an audit of the Ethos. If no changes are proposed within 30 days of said audit, the responsibility will fall on Project Management to propose changes to Ethos in a way they see fit.

7. Proposed Changes to the Ethos (After the preliminary period of 90 days POST-Introduction to the community) shall require a 75% Majority vote of High Command to implement. During the 90 day period, Changes shall require a simple majority vote of High Command to establish changes. Errors and small wording changes / closing of loopholes will not require a vote, and simply 3 heads of staff to sign off.

Checks and Balances

1. If a PR that fits Ethos is denied by Content Review, any Head of Staff can bring the PR to review in High Command that is viewable by staff. A High Command vote requires a simple 50% majority. High Command can choose to request changes, Ignore CR's requested changes, Approve with no changes, or Deny. If a PR is denied by High Command, it is considered dead. If a reversal / decision is made by High Command that goes against CR's decision, there should be a detailed explanation as to why, as well as addressing any major concerns that were brought up during the CR process by reviewers.

2. If a PR is denied by Content Review, the author may form an appeal, in which case the PR must be voted on as listed above on C&B #1. Any denial formed by content review, must disclose the option to appeal.

3. Maintainers can deny a PR or feature based on, but not limited to, short- or long-term maintainability concerns, performance concerns, unfixable bugs with implementation, and server stability concerns, regardless of CR’s or High Command’s decision. Maintainers must provide analysis, metrics, incidents, bug reports, or any other documentation to support their decision. (aka there has to be a functional reason, they cannot deny because they don’t like it)