Merge pull request #75 from DSACMS/nat/tier4-review

Tier 4 Template Review

Author: natalialuzuriaga

tier4/{{cookiecutter.project_slug}}/CODEOWNERS.md

@@ -1,8 +1,8 @@
 # Code Owners
-<!--#TODO Who are the points of contact in your project who are responsible/accountable for the project? This can often be an engineering or design manager or leader, who may or may not be the primary maintainers of the project. List them by GitHub Username-->
+<!-- TODO: Who are the points of contact in your project who are responsible/accountable for the project? This can often be an engineering or design manager or leader, who may or may not be the primary maintainers of the project. List them by GitHub Username-->
 {usernames of code owners}
 
 # Repo Domains
-<!--#TODO List out the various domains of the project or teams of owners for that domain (e.g. Frontend, Backend, Documentation)-->
+<!-- TODO: List out the various domains of the project or teams of owners for that domain (e.g. Frontend, Backend, Documentation)-->
 documentation/* {usernames of documentation owners}
 frontend/* {usernames of frontend owners}

tier4/{{cookiecutter.project_slug}}/COMMUNITY_GUIDELINES.md

@@ -13,7 +13,6 @@ These principles guide our data, product, and process decisions, architecture, a
 - Fostering community includes building capacity and making our software and processes accessible to participants with diverse backgrounds and skillsets.
 - Data (and data science) is as important as software and process. We build open data sets where possible.
 - We strive for transparency for algorithms and places we might be introducing bias.
-- We prioritize data sets that address community vulnerabilities for programs in Justice40.
 
 ## Community Guidelines
 

tier4/{{cookiecutter.project_slug}}/CONTRIBUTING.md

@@ -1,4 +1,4 @@
-<!--- # NOTE: Modify sections marked with `TODO` and then rename the file.-->
+<!--- # NOTE: Modify sections marked with `TODO` -->
 
 # How to Contribute
 
@@ -23,46 +23,45 @@ We encourage you to read this project's CONTRIBUTING policy (you are here), its
 
 ### 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!-->
+<!--- 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! -->
+<!--- TODO: Be sure to include build scripts and instructions, not just the source code itself! -->
 
 ### Workflow and Branching
 
-<!---
-TODO: Workflow Example
+<!--- TODO: Workflow Example
 We follow the [GitHub Flow Workflow](https://guides.github.com/introduction/flow/)
 
 1.  Fork the project
-1.  Check out the `main` branch
-1.  Create a feature branch
-1.  Write code and tests for your change
-1.  From your branch, make a pull request against `cmsgov/cmsgov-example-repo/main`
-1.  Work with repo maintainers to get your change reviewed
-1.  Wait for your change to be pulled into `cmsgov/cmsgov-example-repo/main`
-1.  Delete your feature branch
+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 `cmsgov/cmsgov-example-repo/main`
+6.  Work with repo maintainers to get your change reviewed
+7.  Wait for your change to be pulled into `cmsgov/cmsgov-example-repo/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. -->
+<!--- 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, esliint for JavaScript, etc...)
 
 1. Mention any style guides you adhere to (e.g. pep8, etc...)
-1. Mention any linters your project uses (e.g. flake8, jslint, etc...)
-1. Mention any naming conventions your project uses (e.g. Semantic Versioning, CamelCasing, etc...)
-1. Mention any other content guidelines the project adheres to (e.g. plainlanguage.gov, 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
+<!--- TODO: Example Issue Guides
 
 When creating an issue please try to adhere to the following format:
 
@@ -85,7 +84,7 @@ When creating an issue please try to adhere to the following format:
 
 ### Writing Pull Requests
 
-<!-- ### TODO: Make a brief statement about where to file pull/merge requests, and conventions for doing so. Link to PULL_REQUEST_TEMPLATE.md file.
+<!-- TODO: Make a brief statement about where to file pull/merge requests, and conventions for doing so. Link to PULL_REQUEST_TEMPLATE.md file.
 
 Comments should be formatted to a width no greater than 80 columns.
 
@@ -126,9 +125,7 @@ Some important notes regarding the summary line:
 
 ## Reviewing Pull Requests
 
-<!--- TODO:
-
-### TODO: Make a brief statement about how pull-requests are reviewed, and who is doing the reviewing. Linking to MAINTAINERS.md can help.
+<!--- TODO: Make a brief statement about how pull-requests are reviewed, and who is doing the reviewing. Linking to MAINTAINERS.md can help.
 
 Code Review Example
 
@@ -153,25 +150,22 @@ authorship metadata will be preserved.
 
 -->
 
+
 ## Shipping Releases
 
-<!--#TODO: What cadence does your project ship new releases? (e.g. one-time, ad-hoc, periodically, upon merge of new patches) Who does so?-->
+<!-- TODO: What cadence does your project ship new releases? (e.g. one-time, ad-hoc, periodically, upon merge of new patches) Who does so? -->
+
 
 ## Documentation
 
-<!--TODO: Documentation Example
+<!-- TODO: Documentation Example
 
 We also welcome improvements to the project documentation or to the existing
 docs. Please file an [issue](https://github.com/cmsgov/cmsgov-example-repo/issues).
 -->
 
 ## Policies
 
-<!-- TODO: This section is here to explicitly link to Federal policies and
-guidelines that are required or recommended for Federal projects to comply
-with, such as Accessibility (508) Interoperability, Anti-deficiency, Security,
-Licensing, and other policies that can vary between agencies and domains.-->
-
 ### Open Source Policy
 
 We adhere to the [CMS Open Source
@@ -190,6 +184,6 @@ For more information about our Security, Vulnerability, and Responsible Disclosu
 
 ## 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/).
+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.
+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.

tier4/{{cookiecutter.project_slug}}/GOVERNANCE.md

@@ -1,5 +1,5 @@
 # Governance
-<!--TODO: Starting at Tier 3 GOVERNANCE.md has basic language about early community governance, how the project make decisions, and how contirbutors are elevated through the leadership process if any (e.g. joining teams, getting maintainer status, etc...)
+<!-- TODO: Starting at Tier 3 GOVERNANCE.md has basic language about early community governance, how the project make decisions, and how contirbutors are elevated through the leadership process if any (e.g. joining teams, getting maintainer status, etc...)
 -->
 
 This project is governed by our [Community Guidelines](COMMUNITY_GUIDELINES.md) and [Code of Conduct](CODE_OF_CONDUCT.md). 

tier4/{{cookiecutter.project_slug}}/MAINTAINERS.md

@@ -1,11 +1,11 @@
 # Maintainers
-<!-- TODO Who are the points of contact in your project who are responsible/accountable for the project? This can often be an engineering or design manager or leader, who may or may not be the primary maintainers of the project.-->
+<!-- TODO: Who are the points of contact in your project who are responsible/accountable for the project? This can often be an engineering or design manager or leader, who may or may not be the primary maintainers of the project.-->
 This is a list of maintainers for this project. See CODEOWNERS.md for list of reviewers for different parts of the codebase. Team members include:
 
 {list or table including the fields: role, name, affiliation, github username}
 
 # Maintainers Table
-<!-- TODO What groups/domains are maintainers a part of? Does your project have domains/areas that are maintained by specific people? List @USERNAMES directly, or any @ALIASES for groups/teams.-->
+<!-- TODO: What groups/domains are maintainers a part of? Does your project have domains/areas that are maintained by specific people? List @USERNAMES directly, or any @ALIASES for groups/teams.-->
 
 |Role |Name |Github Username |Affiliation|
 |:-----|:-----|:-----|:-----|

tier4/{{cookiecutter.project_slug}}/README.md

@@ -16,29 +16,32 @@
 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.-->
+
+<!-- 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.-->
+
+<!-- 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. -->
+
 **{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 externabl contributors will need to fork the project and will not be able to merge their own pull requests. For more information on contribributing, 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.
--->
+
+<!--- 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
-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.
--->
+
+<!-- TODO: 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:
+
+<!--- 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.
@@ -52,7 +55,6 @@ This project uses **continuous deployment** using [Github Actions](https://githu
 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).
 
@@ -70,15 +72,15 @@ We also recognize capacity building as a key part of involving a diverse open so
 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. 
 
 ## Governance
-<!--#TODO: Make a short statement about how the project is governed (formally, or informally) and link to the GOVERNANCE.md file.-->
+
+<!-- TODO: Make a short statement about how the project is governed (formally, or informally) and link to the GOVERNANCE.md file.-->
 
 ## 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
@@ -95,10 +97,10 @@ email or via GitHub Issues. Please use our website to submit vulnerabilities at
 HHS maintains an acknowledgements page to recognize your efforts on behalf of
 the American public, but you are also welcome to submit anonymously.
 
-For more information about our Security, Vulnerability, and Responsible Disclosure Policies, see [SECURITY.md](SECURITY.md) as indicated in [LICENSE](LICENSE).
+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/).
+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.