Merge pull request #1 from DSACMS/repolinter-results-#1

Repolinter Results

CONTRIBUTING.md

@@ -0,0 +1,70 @@
+# Contributing Guidelines 
+<!-- Basic instructions about where to send patches, check out source code, and get development support.--> 
+
+ We're so thankful you're considering contributing to an [open source project of the U.S. government](https://code.gov/)! If you're unsure about anything, just ask -- or submit the issue or pull request anyway. The worst that can happen is you'll be politely asked to change something. We appreciate all friendly contributions.
+
+ We encourage you to read this project's CONTRIBUTING policy (you are here), its [LICENSE](LICENSE.md), and its [README](README.md). 
+
+ ## Getting Started 
+<!--- TODO: If you have 'good-first-issue' or 'easy' labels for newcomers, mention them here.--> 
+
+ ### Building Dependencies 
+<!--- TODO: This step is often skipped, so don't forget to include the steps needed to install on your platform. If you project can be multi-platform, this is an excellent place for first time contributors to send patches!--> 
+
+ ### Building the Project 
+<!--- TODO: Be sure to include build scripts and instructions, not just the source code itself! -->
+
+ ### Workflow and Branching 
+<!--- TODO: Workflow Example
+We follow the [GitHub Flow Workflow](https://guides.github.com/introduction/flow/)
+1.  Fork the project
+2.  Check out the `main` branch
+3.  Create a feature branch
+4.  Write code and tests for your change
+5.  From your branch, make a pull request against `{{ cookiecutter.project_org }}/{{ cookiecutter.project_repo_name }}/main`
+6.  Work with repo maintainers to get your change reviewed
+7.  Wait for your change to be pulled into `{{ cookiecutter.project_org }}/{{ cookiecutter.project_repo_name }}/main`
+8.  Delete your feature branch
+-->
+
+ ### Testing Conventions 
+<!--- TODO: Discuss where tests can be found, how they are run, and what kind of tests/coverage strategy and goals the project has. --> 
+
+ ### Coding Style and Linters 
+<!--- TODO: HIGHLY ENCOURAGED. Specific tools will vary between different languages/frameworks (e.g. Black for python, eslint for JavaScript, etc...)
+1. Mention any style guides you adhere to (e.g. pep8, etc...)
+2. Mention any linters your project uses (e.g. flake8, jslint, etc...)
+3. Mention any naming conventions your project uses (e.g. Semantic Versioning, CamelCasing, etc...)
+4. Mention any other content guidelines the project adheres to (e.g. plainlanguage.gov, etc...)
+--> 
+
+ ### Writing Issues 
+<!--- TODO: Example Issue Guides
+ When creating an issue please try to adhere to the following format:
+ module-name: One line summary of the issue (less than 72 characters)
+ ### Expected behavior
+ As concisely as possible, describe the expected behavior.
+ ### Actual behavior
+ As concisely as possible, describe the observed behavior.
+ ### Steps to reproduce the behavior
+ List all relevant steps to reproduce the observed behavior.
+ see our .github/ISSUE_TEMPLATE.md for more examples.
+ -->
+
+ ## Documentation 
+<!-- TODO: Documentation Example 
+We also welcome improvements to the project documentation or to the existing docs. Please file an [issue](https://github.com/{{ cookiecutter.project_org }}/{{ cookiecutter.project_repo_name }}/issues).
+ --> 
+
+ ## Policies 
+
+ ### Open Source Policy 
+We adhere to the [CMS Open Source Policy](https://github.com/CMSGov/cms-open-source-policy). If you have any questions, just [shoot us an email](mailto:[email protected]).
+
+ ### Security and Responsible Disclosure Policy 
+*Submit a vulnerability:* Vulnerability reports can be submitted through [Bugcrowd](https://bugcrowd.com/cms-vdp). Reports may be submitted anonymously. If you share contact information, we will acknowledge receipt of your report within 3 business days.
+ For more information about our Security, Vulnerability, and Responsible Disclosure Policies, see [SECURITY.md](SECURITY.md).
+
+ ## 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/) as indicated in [LICENSE](LICENSE).
+ All contributions to this project will be released under the CC0 dedication. By submitting a pull request or issue, you are agreeing to comply with this waiver of copyright interest.

LICENSE

@@ -0,0 +1,2 @@
+# License 
+Remove this line and attach the license that is being used for this project. For helping choosing a license, visit this website: https://choosealicense.com/ 

README.md

@@ -0,0 +1,93 @@
+# Repolinter Test 1
+<!-- This should be 1-3 sentence short description of the project that can be used as a 'one-liner' to describe the repo. A best practice is using this same language as the official 'description' on a GitHub repo landing page. --> 
+This is a quick test project.
+
+ ## About the Project 
+<!-- This should be a longer-form description of the project. It can include history, background, details, problem statements, links to design documents or other supporting materials, or any other information/context that a user or contributor might be interested in. --> 
+This is a real quick test project for Repolinter PR testing the actual flow of using this action.
+
+ ## Project Mission 
+<!-- Provide the core mission and objectives driving this project. --> 
+
+ ## Agency Mission 
+<!-- Provide the mission of the agency and how this project aligns. --> 
+
+ ## Team Mission 
+<!-- Provide the team's mission and how they work together. --> 
+
+ ## Core Team 
+An up-to-date list of core team members can be found in [MAINTAINERS.md](MAINTAINERS.md). At this time, the project is still building the core team and defining roles and responsibilities. We are eagerly seeking individuals who would like to join the community and help us define and fill these roles. 
+
+ ## Documentation Index 
+<!-- TODO: This is a like a 'table of contents' for your documentation. Tier 0/1 projects with simple README.md files without many sections may or may not need this, but it is still extremely helpful to provide 'bookmark' or 'anchor' links to specific sections of your file to be referenced in tickets, docs, or other communication channels. --> 
+ **{list of .md at top directory and descriptions}** 
+
+ ## Repository Structure 
+<!-- TODO: Using the 'tree -d' command can be a helpful way to generate this information, but, be sure to update it as the project evolves and changes over time. --> 
+ <!--TREE START--><!--TREE END--> 
+ **{list directories and descriptions}** 
+
+ ## Development and Software Delivery Lifecycle 
+The following guide is for members of the project team who have access to the repository as well as code contributors. The main difference between internal and external contributions is that external contributors will need to fork the project and will not be able to merge their own pull requests. For more information on contributing, see: [CONTRIBUTING.md](./CONTRIBUTING.md). 
+
+ ## Local Development 
+<!--- TODO - with example below: 
+This project is monorepo with several apps. Please see the [api](./api/README.md) and [frontend](./frontend/README.md) READMEs for information on spinning up those projects locally. Also see the project [documentation](./documentation) for more info. --> 
+
+ ## Coding Style and Linters 
+<!-- TODO - Add the repo's linting and code style guidelines --> 
+ Each application has its own linting and testing guidelines. Lint and code tests are run on each commit, so linters and tests should be run locally before commiting. 
+
+ ## Branching Model 
+ <!-- TODO - with example below:
+ This project follows [trunk-based development](https://trunkbaseddevelopment.com/), which means:
+
+* Make small changes in [short-lived feature branches](https://trunkbaseddevelopment.com/short-lived-feature-branches/) and merge to `main` frequently.
+* Be open to submitting multiple small pull requests for a single ticket (i.e. reference the same ticket across multiple pull requests).
+* Treat each change you merge to `main` as immediately deployable to production. Do not merge changes that depend on subsequent changes you plan to make, even if you plan to make those changes shortly.
+* Ticket any unfinished or partially finished work.
+* Tests should be written for changes introduced, and adhere to the text percentage threshold determined by the project.
+
+This project uses **continuous deployment** using [Github Actions](https://github.com/features/actions) which is configured in the [./github/workflows](.github/workflows) directory.
+
+Pull-requests are merged to `main` and the changes are immediately deployed to the development environment. Releases are created to push changes to production.--> 
+
+ ## Contributing 
+Thank you for considering contributing to an Open Source project of the US Government! For more information about our contribution guidelines, see [CONTRIBUTING.md](CONTRIBUTING.md). 
+
+ ## Codeowners 
+The contents of this repository are managed by **{responsible organization(s)}**. Those responsible for the code and documentation in this repository can be found in [CODEOWNERS.md](CODEOWNERS.md). 
+
+ ## Community 
+The {name_of_project_here} team is taking a community-first and open source approach to the product development of this tool. We believe government software should be made in the open and be built and licensed such that anyone can download the code, run it themselves without paying money to third parties or using proprietary software, and use it as they will.
+
+We know that we can learn from a wide variety of communities, including those who will use or will be impacted by the tool, who are experts in technology, or who have experience with similar technologies deployed in other spaces. We are dedicated to creating forums for continuous conversation and feedback to help shape the design and development of the tool.
+
+We also recognize capacity building as a key part of involving a diverse open source community. We are doing our best to use accessible language, provide technical and process documents, and offer support to community members with a wide variety of backgrounds and skillsets. 
+
+ ## Community Guidelines 
+Principles and guidelines for participating in our open source community are can be found in [COMMUNITY_GUIDELINES.md](COMMUNITY_GUIDELINES.md). Please read them before joining or starting a conversation in this repo or one of the channels listed below. All community members and participants are expected to adhere to the community guidelines and code of conduct when participating in community spaces including: code repositories, communication channels and venues, and events. 
+
+ ## Feedback 
+If you have ideas for how we can improve or add to our capacity building efforts and methods for welcoming people into our community, please let us know at **{contact_email}**. If you would like to comment on the tool itself, please let us know by filing an **issue on our GitHub repository.** 
+
+ ## Glossary 
+Information about terminology and acronyms used in this documentation may be found in [GLOSSARY.md](GLOSSARY.md). 
+
+ ## Policies 
+
+ ### Open Source Policy 
+We adhere to the [CMS Open Source Policy](https://github.com/CMSGov/cms-open-source-policy). If you have any questions, just [shoot us an email](mailto:[email protected]). 
+
+ ### Security and Responsible Disclosure Policy 
+*Submit a vulnerability:* Vulnerability reports can be submitted through [Bugcrowd](https://bugcrowd.com/cms-vdp). Reports may be submitted anonymously. If you share contact information, we will acknowledge receipt of your report within 3 business days.
+For more information about our Security, Vulnerability, and Responsible Disclosure Policies, see [SECURITY.md](SECURITY.md). 
+
+ ## 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/) as indicated in [LICENSE](LICENSE).
+All contributions to this project will be released under the CC0 dedication. By submitting a pull request or issue, you are agreeing to comply with this waiver of copyright interest.
+
+ ### Software Bill of Materials (SBOM) 
+A Software Bill of Materials (SBOM) is a formal record containing the details and supply chain relationships of various components used in building software.
+In the spirit of [Executive Order 14028 - Improving the Nation's Cyber Security](https://www.gsa.gov/technology/it-contract-vehicles-and-purchasing-programs/information-technology-category/it-security/executive-order-14028), a SBOM for this repository is provided here: https://github.com/{repo_org}/{repo_name}/network/dependencies.
+For more information and resources about SBOMs, visit: https://www.cisa.gov/sbom.

SECURITY.md

@@ -0,0 +1,9 @@
+# Security and Responsible Disclosure Policy 
+The Centers for Medicare & Medicaid Services is committed to ensuring the security of the American public by protecting their information from unwarranted disclosure. We want security researchers to feel comfortable reporting vulnerabilities they have discovered so we can fix them and keep our users safe. We developed our disclosure policy to reflect our values and uphold our sense of responsibility to security researchers who share their expertise with us in good faith. 
+
+ *Submit a vulnerability:* Vulnerability reports can be submitted through [Bugcrowd](https://bugcrowd.com/cms-vdp). Reports may be submitted anonymously. If you share contact information, we will acknowledge receipt of your report within 3 business days. 
+
+ Review the HHS Disclosure Policy and websites in scope: 
+ [https://www.hhs.gov/vulnerability-disclosure-policy/index.html](https://www.hhs.gov/vulnerability-disclosure-policy/index.html). 
+
+ This policy describes *what systems and types of research* are covered under this policy, *how to send* us vulnerability reports, and *how long* we ask security researchers to wait before publicly disclosing vulnerabilities.