chore(docs): Add team-norms section and onboarding updates. (#320)

* start of norms

* docs

* PRs

* Add zscaler and snyk access instructions

* spacing

* formatting

* rename to account access

* PR updates

* Verbage

---------

Co-authored-by: Benjamin Paige <[email protected]>

docs/docs/onboarding/account-access.md → docs/docs/onboarding/access-requests.md

@@ -1,11 +1,11 @@
 ---
 layout: default
-title: Account Access
+title: Access Requests
 parent: Onboarding
 nav_order: 2
 ---
 
-# Account Access
+# Access Requests
 {: .no_toc }
 
 You'll need access to a few systems to be a fully privileged developer.  This section will guide you in making the necessary access requests.  
@@ -46,6 +46,37 @@ So, to have full AWS access, you will need two things:  access to the Cloud VPN
 
 Please [follow this how-to guide](https://qmacbis.atlassian.net/l/cp/yY5s5is2) to obtain access to AWS and the Cloud VPN.
 
+## Zscaler VPN
+
+This project communicates with Seatool.  Sometimes, during development, access to the Seatool frontend is helpful.  To gain access to it, you must first get access to the Zscaler VPN.
+
+Please follow these [instructions to gain access to Zscaler](https://qmacbis.atlassian.net/wiki/spaces/DE/pages/3180560407/How+to+get+access+to+CMS+Zscaler+VPN+Access).
+
+## Snyk
+
+Snyk is a software tool that specializes in identifying and resolving security vulnerabilities in code dependencies and performing static code analysis. It scans project dependencies for known security issues and provides recommendations for fixing them, enhancing code security.
+
+CMS has a Snyk installation that our project ties into.  It can be found [https://snyk.cms.gov/](here).  Access is governed by a CMS job code, as well as Snyk permissions.
+
+Please follow these steps to gain access to Snyk:
+1. Request / Confirm EUA job code: ENT_APPSEC_TOOLS: Access to Enterprise Application Security Tools: Snyk
+2. Login to Enterprise User Administration (EUA)
+3. Select View My Identity
+4. Select the "Job Codes" tab
+5. Review your current Job Codes.  Do you have ENT_APPSEC_TOOLS?
+6. If no, request job code ENT_APPSEC_TOOLS
+- On the “Task” sidebar select “Modify My Job Codes
+- Be sure to select the “*Confirmation (Required) check box
+- Select Next
+- At the bottom left of the page select “Add a Job Code”
+- Enter the job code you want to add, In this case ENT_APPSEC_TOOLS and select “Search”
+- Check the select box and click the “Select” bottom.
+- Click “Next”
+- Enter a “Justification Reason” and select “Finish”
+- Example: I am a CMS contractor, requesting Access to Enterprise Application Security Tools: Snyk order to support development and maintenance of the suite of MACPRO systems supported by Fearless and it’s sub-contractors under Primary Contract Number: GS-35F-115GA:75FCMC22F0093:
+- Now wait for the request to be approved. You need ENT_APPSEC_TOOLS before the cloud team will setup your access.
+7. Let me know when each user has confirmed that you have the ENT_APPSEC_TOOLS the Job Code and I will send a Snyk invite the email address associated with their EUA ID.
+
 ## Code Climate
 
 We use [Code Climate](https://codeclimate.com/) to monitor project quality.  This includes running maintainability checks for Pull Requests, which flags code that doesn't meet best practices.  Checks include function length, file length, cognitive complexity, and duplication.

docs/docs/team-norms/pull-requests.md

@@ -0,0 +1,65 @@
+---
+layout: default
+title: Pull Requests
+parent: Team Norms
+nav_order: 1
+---
+
+# Pull Requests
+
+## Introduction
+
+Pull Requests (PRs) are an essential part of our software development process, enabling code review, discussion, and integration. This document outlines our team norms regarding PRs to ensure a smooth, efficient, and collaborative workflow.
+
+Above all else, please remember: your discretion and judgement supersedes this document.  If you're creating or reviewing a Pull Request that needs to break any of these norms for good reason, that's OK.  This document is the rule; exceptions are expected.
+
+## Creating Pull Requests
+
+### Content and Format
+
+- **Title**: The title of your PR should be carefully considered. It should be descriptive enough to convey the essence of the changes but concise enough to be easily readable. Think of the title as a brief summary that helps others quickly understand the purpose of the PR.
+- **Follow the Template**: We use a Pull Request template to standardize and streamline our PR descriptions. It is expected that all PRs will adhere to this template.
+
+### Small, Focused Changes
+
+- **Scope**: Keep PRs focused on a single task or issue to simplify review and discussion.  While most pull requests will each address a single ticket, it's OK to handle multiple Jira tickets in one PR when it makes sense.
+- **Size**: Aim for small, manageable PRs. Large PRs should be broken down into smaller parts if possible.
+- **Formatters**: Be conscious of formatting updates that your IDE may make automatically, or that you may make along the way.  Sometimes small, non-functional code changes can clutter a pull request.
+
+## Reviewing Pull Requests
+
+### Timeliness
+
+- **Prompt Reviews**: Team members are expected to review PRs in a timely manner, typically next day or sooner.
+
+### Constructive Feedback
+
+- **Respectful Communication**: Provide constructive, respectful feedback.
+- **Specific Comments**: Use specific comments to point out issues, suggest improvements, or ask clarifying questions.
+
+### Testing
+
+- **Test as Appropriate**: The burden of full end to end testing lies with the author, our automated testing frameworks, and any manual QA process. However, reviewers should test the environment when they think it necessary, perhaps when they've thought of an edge case that might not be covered.
+- **Explain your testing**: The PR approach should typically include some detail around how manual tests were performed.  This helps greatly in allowing reviewers to sign off without needing to test individually.
+
+## Merging Pull Requests
+
+### Passing Checks
+
+- **CI/CD**: Ensure all continuous integration and deployment checks have passed.
+- **Code Quality**: Code should meet our standards for quality and maintainability.
+
+### Approval
+
+- **Minimum Approvals**: PRs require a minimum number of approvals (1) from the team members before merging.
+- **Outstanding Comments**: If there are comments that ask for action or consideration to be made by the author, please address them prior to merge, regardless if you have approval.
+
+### Merging
+- **Author Merges**: After receiving necessary approvals, the PR author is responsible for merging the code.
+- **Squashing Protocol**: When merging into the master branch, always squash and merge.  When merging into val and production, create a merge commit.
+- **Commit Messages**: We use semantic release to automatically release our product.  Semantic Release looks for commit messages with special [commit message syntax](https://semantic-release.gitbook.io/semantic-release/#commit-message-format).  Please follow this syntax when crafting your commit message.  Note: GitHub will use your PR title as the default commit message when squashing; so, it's recommended to set your PR title equal to the semantic release commit message appropriate for your changeset.
+
+## Responsibility and Accountability
+
+- **Ownership**: The author is responsible for addressing feedback and ensuring the PR is ready for merging.
+- **Collaboration**: All team members share the responsibility for maintaining a high standard of code through thoughtful PR reviews.

docs/docs/team-norms/team-norms.md

@@ -0,0 +1,15 @@
+---
+layout: default
+title: Team Norms
+nav_order: 3
+has_children: true
+permalink: docs/team-norms
+---
+
+# Team Norms
+{: .no_toc }
+
+What's expected and what you can expect 
+{: .fs-6 .fw-300 }
+
+wip