Add RELEASES.md and CONTRIBUTING.md to project (#936)

* Add new`CONTRIBUTING.md` file

* Add new `RELEASE.md` file to project

* Rename to RELEASES.md

* Clarify patch release commit selection

* Expand release notes instructions

CONTRIBUTING.md

@@ -0,0 +1,58 @@
+# Welcome #
+
+We're so glad you're thinking about contributing to ScubaGear! If
+you're unsure or hesitant to make a recommendation, just ask, submit
+the issue, or pull request. The worst that can happen is that you'll
+be politely asked to change something. We appreciate any sort of
+contribution(s), and don't want a wall of rules to stifle innovation.
+
+Before contributing, we encourage you to read our CONTRIBUTING policy
+(you are here), our
+[LICENSE](https://github.com/cisagov/ScubaGear/blob/main/LICENSE),
+and our
+[README](https://github.com/cisagov/ScubaGear/blob/main/README.md),
+all of which are in this repository.
+
+## Issues ##
+
+If you want to report a bug or request a new feature, the most direct
+method is to
+[create an issue](https://github.com/cisagov/ScubaGear/issues) in
+this repository. We recommend that you first search through existing
+open and closed issues to check if your particular issue has already
+been reported.
+
+If it has then you might want to add a comment to the existing issue.
+
+If it hasn't then feel free to create a new one.
+
+Please follow the provided template and fill out all sections.
+We have `Bug Report` and `Idea` templates.
+
+## Pull Requests (PR) ##
+
+If you choose to [submit a pull
+request](https://github.com/cisagov/ScubaGear/pulls), it must pass
+several style, format, and sanity checks in our continuous
+integration (CI) pipeline before it can be merged. Your pull request
+may fail these checks, and that's OK. If you want you can stop there
+and wait for us to make the necessary corrections to ensure your code
+passes the CI checks. If you would rather make the changes yourself
+to pass the CI checks, please feel free to do so.
+
+### Quality assurance and code reviews ##
+
+All PRs will be tested, vetted, and reviewed by our team before being
+merged to the main branch. Please stand by to address questions,
+concerns, or improvement suggestions we may have about your PR.
+
+## Public domain ##
+
+This project is in the public domain within the United States, and
+copyright and related rights in the work worldwide are waived through
+the [CC0 1.0 Universal public domain
+dedication](https://creativecommons.org/publicdomain/zero/1.0/).
+
+All contributions to this project will be released under the CC0
+dedication. By submitting a pull request, you are agreeing to comply
+with this waiver of copyright interest.

RELEASES.md

@@ -0,0 +1,59 @@
+# ScubaGear Release Process <!-- omit in toc --> #
+
+This document outlines the ScubaGear software release process.
+
+## Table of Contents <!-- omit in toc --> ##
+
+- [Versioning](#versioning)
+- [Release branches and tags](#release-branches-and-tags)
+- [Preparing ScubaGear release candidate](#preparing-scubagear-release-candidate)
+- [Publishing ScubaGear release candidate](#publishing-scubagear-release-candidate)
+
+## Versioning ##
+
+ScubaGear releases use the Semantic Versioning specification [v2.0](https://semver.org/spec/v2.0.0.html) to number its releases.  As such release versions take the form of MAJOR.MINOR.PATCH where:
+* MAJOR version when you make incompatible API changes
+* MINOR version when you add functionality in a backward compatible manner
+* PATCH version when you make backward compatible bug fixes
+
+Additional labels for pre-release and build metadata may also be used as extensions to the MAJOR.MINOR.PATCH format, as determined by the development team.
+
+Note that ScubaGear versions and Secure Configuration Baseline (SCB) policy versions are distinct, but related.  That is, a given version of ScubaGear may operate on one or more SCB, or baseline, versions.  A given ScubaGear version assesses against the baseline version included in the release package.  ScubaGear reports include both the tool and baseline versions for reference.
+
+## Release branches and tags ##
+
+ScubaGear major and minor releases are built directly from the main branch.  Branch protections prevent direct push to the main branch.  All changes require a pull request and associated review prior to merge. 
+When a new release is planned, the latest commit to be included is tagged with its release versions (e.g., vX.Y.Z).  Patch versions are created from a separate release branch named `release-X.Y.Z` and are branched from the latest release tag or previous patch release branch which they are patching. The patch release branch contains only the cherry picked commits that resolve an identified bug the patch release resolves along with version bumps.
+
+## Preparing ScubaGear release candidate ##
+
+The checklist below is used by the development team when it prepares a new release.  The goal of the list below is to ensure consistency and quality in the resulting releases.
+
+- [ ] Ensure all [blocked](https://github.com/cisagov/ScubaGear/labels/) issues and pull requests are resolved.
+- [ ] (future) Update CHANGELOG
+- [ ] Validate that all tests pass on CI for the release branch before proceeding
+- [ ] Update ModuleVersion in the [manifest](https://github.com/cisagov/ScubaGear/blob/main/PowerShell/ScubaGear/ScubaGear.psd1) to match release version
+- [ ] Update the module version in the [README.md](https://github.com/cisagov/ScubaGear/blob/main/README.md) badge image link and release download artifact name.
+- [ ] Check and update copyright dates in [manifest](https://github.com/cisagov/ScubaGear/blob/main/PowerShell/ScubaGear/ScubaGear.psd1) as needed
+- [ ] If baselines changed, update `baseline_version` in [Orchestrator module](https://github.com/cisagov/ScubaGear/blob/main/PowerShell/ScubaGear/Modules/Orchestrator.psm1)
+- [ ] Update and redact the sample report using the redaction tool and manual review
+- [ ] Check README for any necessary changes and documentation updates as needed
+- [ ] Build initial release candidate by manually triggering `Build and Sign Release` action with expected release name (vX.X.X) and release version (X.X.X) based on semantic versioning
+- [ ] Conduct automated release testing of each baseline
+- [ ] Fix critical defects deemed release blocking
+- [ ] Document non-critical issues for future development cycle
+- [ ] If fixes applied, restart release process
+
+## Publishing ScubaGear release candidate ##
+
+After running the `Build and Sign Release` workflow, a draft release will be visible to development team members for review and revision.  The checklist below is designed to ensure consistency in review and publishing of the release candidate as the final release. 
+
+- [ ] Update release notes manually
+  - Adjust default change format to use PR listing as `- #{{TITLE}} ##{{NUMBER}}`
+  - Regroup changes into sections: Major new features, Bug fixes, Documentation improvements, and Baseline updates
+- [ ] Make the release official and visible to public
+  - Uncheck **Set as a pre-release**
+  - Check **Set as latest release**
+  - Click **Publish Release**
+- [ ] Verify that the new release is shown as latest on GitHub repository main page
+- [ ] Validate that the new release has been published to PSGallery