[ISSUE 549] Update terraform to support move to simpler.grants.gov (#608

)

.github/ISSUE_TEMPLATE/adr.yml

@@ -12,7 +12,7 @@ body:
   - type: markdown
     attributes:
       value: |
-        **Example** [Wiki ADR](https://github.com/HHS/grants-equity/issues/30)
+        **Example** [Wiki ADR](https://github.com/HHS/simpler-grants-gov/issues/30)
   - type: textarea
     id: description
     attributes:

.github/ISSUE_TEMPLATE/milestone.yml

@@ -12,7 +12,7 @@ body:
   - type: markdown
     attributes:
       value: |
-        **Example:** [DB & API Planning](https://github.com/HHS/grants-equity/issues/21)
+        **Example:** [DB & API Planning](https://github.com/HHS/simpler-grants-gov/issues/21)
   - type: textarea
     id: description
     attributes:

COMMUNITY_GUIDELINES.md

@@ -6,31 +6,31 @@ We know that we can learn from a wide variety of communities, including those wh
 
 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 in multiple languages, and offer support to community members with a wide variety of backgrounds and skillsets. 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 by filing an issue on our GitHub repository.
 
-## Principles 
+## Principles
 
-Principles and guidelines for participating in our open source community are linked belowhere. 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. 
+Principles and guidelines for participating in our open source community are linked belowhere. 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.
 
 These principles guide our data, product, and process decisions, architecture, and approach. These guidelines are inspired by the [Justice40 Community Guidelines](https://github.com/usds/justice40-tool/blob/main/COMMUNITY_GUIDELINES.md).
 
-* Open means transparent and participatory.
-* We take a modular and modern approach to software development.
-* We build open-source software and open-source processes.
-* We value ease of implementation.
-* 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.
+- Open means transparent and participatory.
+- We take a modular and modern approach to software development.
+- We build open-source software and open-source processes.
+- We value ease of implementation.
+- 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.
 
 All community members are expected to adhere to our [Code of Conduct](CODE_OF_CONDUCT.md).
 
 ## Community Guidelines
 
-* When participating in the Grants Equity open source community conversations and spaces, we ask individuals to follow the following guidelines:
-* When joining a conversation for the first time, please introduce yourself by providing a brief intro that includes:
-  * your related organization (if applicable)
-  * your pronouns, if you would like to share those
-  * disclosure of any current or potential financial interest in this work
-  * your superpower, and how you hope to use it for this project
-* Embrace a culture of learning, and educate each other. We are all entering this conversation from different starting points and with different backgrounds. There are no dumb questions.
-* Take space and give space. We strive to create an equitable environment in which all are welcome and able to participate. We hope individuals feel comfortable voicing their opinions and providing contributions and will do our best to recognize and make space for individuals who may be struggling to find space here. Likewise, we expect individuals to recognize when they are taking up significant space and take a step back to allow room for others.
-* Be present when joining synchronous conversations such as our community chat. Why be here if you're not going to be here?
-* Be respectful.
+- When participating in the Simpler Grants open source community conversations and spaces, we ask individuals to follow the following guidelines:
+- When joining a conversation for the first time, please introduce yourself by providing a brief intro that includes:
+  - your related organization (if applicable)
+  - your pronouns, if you would like to share those
+  - disclosure of any current or potential financial interest in this work
+  - your superpower, and how you hope to use it for this project
+- Embrace a culture of learning, and educate each other. We are all entering this conversation from different starting points and with different backgrounds. There are no dumb questions.
+- Take space and give space. We strive to create an equitable environment in which all are welcome and able to participate. We hope individuals feel comfortable voicing their opinions and providing contributions and will do our best to recognize and make space for individuals who may be struggling to find space here. Likewise, we expect individuals to recognize when they are taking up significant space and take a step back to allow room for others.
+- Be present when joining synchronous conversations such as our community chat. Why be here if you're not going to be here?
+- Be respectful.

CONTRIBUTING.md

@@ -16,11 +16,11 @@ There are a number of ways to contribute to this project.
 
 ### Report a Bug
 
-If you think you have found a bug in the code or static site, [search our issues list](https://github.com/HHS/grants-equity/issues) on GitHub for any similar bugs. If you find a similar bug, please update that issue with your details.
+If you think you have found a bug in the code or static site, [search our issues list](https://github.com/HHS/simpler-grants-gov/issues) on GitHub for any similar bugs. If you find a similar bug, please update that issue with your details.
 
 If you do not find your bug in our issues list, file a bug report. When reporting the bug, please follow these guidelines:
 
-- **Please use the [Bug Report](https://github.com/HHS/grants-equity/issues/new?assignees=octocat&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D%3A+) issue template** This is populated with information and questions that will help grants.gov developers resolve the issuethe right information
+- **Please use the [Bug Report](https://github.com/HHS/simpler-grants-gov/issues/new?assignees=octocat&labels=bug&projects=&template=bug_report.yml&title=%5BBug%5D%3A+) issue template** This is populated with information and questions that will help grants.gov developers resolve the issuethe right information
 - **Use a clear and descriptive issue title** for the issue to identify the problem.
 - **Describe the exact steps to reproduce the problem** in as much detail as possible. For example, start by explaining how you got to the page where you encountered the bug and what you were attempting to do when the bug occurred.
 - **Describe the behavior you observed after following the steps** and point out what exactly is the problem with that behavior.
@@ -32,7 +32,7 @@ If you do not find your bug in our issues list, file a bug report. When reportin
 
 If you don't have specific language or code to submit but would like to suggest a change, request a feature, or have something addressed, you can open an issue in this repository.
 
-Please open an issue of type [Feature request](https://github.com/HHS/grants-equity/issues/new?assignees=octocat&labels=enhancement&projects=&template=feature_request.yml&title=%5BFeature+Request%5D%3A+):
+Please open an issue of type [Feature request](https://github.com/HHS/simpler-grants-gov/issues/new?assignees=octocat&labels=enhancement&projects=&template=feature_request.yml&title=%5BFeature+Request%5D%3A+):
 
 In this issue, please describe the use case for the feature you would like to see -, what you need, why you need it, and how it should work. Team members will respond to the Feature request as soon as possible. Often, Feature request suggestions undergo a collaborative discussion with the community to help refine the need for the feature and how it can be implemented.
 
@@ -46,9 +46,9 @@ To contribute to documentation you find in this repository, feel free to use the
 
 > 🚧 Tools and expanding avenues for community engagement are coming soon.
 
-### Sharing your story 
+### Sharing your story
 
-Sharing how you or your organization have used the Grants Equity project is an important way for us to raise awareness about the project and its impact. Please tell us your story by [sending us an email at `grants-equity@hhs.gov`](mailto:grants-equity@hhs.gov).
+Sharing how you or your organization have used the Simpler Grants project is an important way for us to raise awareness about the project and its impact. Please tell us your story by [sending us an email at `simpler-grants-gov@hhs.gov`](mailto:simpler-grants-gov@hhs.gov).
 
 ## Code Contributions
 
@@ -66,9 +66,9 @@ This project follows [trunk-based development](./DEVELOPMENT.md#branching-model)
 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 `hhs/grants-equity/main`
+1.  From your branch, make a pull request against `hhs/simpler-grants-gov/main`
 1.  Work with repo maintainers to get your change reviewed
-1.  Wait for your change to be pulled into `hhs/grants-equity/main`
+1.  Wait for your change to be pulled into `hhs/simpler-grants-gov/main`
 1.  Delete your feature branch
 
 ### Testing, Coding Style and Linters
@@ -77,7 +77,7 @@ Each application has its own testing and linters. Every commit is tested to adhe
 
 ### Issues
 
-External contributors should use the *Bug Report* or *Feature Request* [issue templates](https://github.com/HHS/grants-equity/issues/new/choose).
+External contributors should use the _Bug Report_ or _Feature Request_ [issue templates](https://github.com/HHS/simpler-grants-gov/issues/new/choose).
 
 ### Pull Requests
 
@@ -97,12 +97,12 @@ We adhere to the [HHS Open Source Policy](https://github.com/CMSGov/cms-open-sou
 The Department of Health and Human 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:* Unfortunately, we cannot accept secure submissions via email or via GitHub Issues. Please use our website to submit vulnerabilities at [https://hhs.responsibledisclosure.com](https://hhs.responsibledisclosure.com). HHS maintains an acknowledgements page to recognize your efforts on behalf of the American public, but you are also welcome to submit anonymously.
+_Submit a vulnerability:_ Unfortunately, we cannot accept secure submissions via email or via GitHub Issues. Please use our website to submit vulnerabilities at [https://hhs.responsibledisclosure.com](https://hhs.responsibledisclosure.com). HHS maintains an acknowledgements page to recognize your efforts on behalf of the American public, but you are also welcome to submit anonymously.
 
 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.
+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.
 
 If you have other cybersecurity related questions, please contact us at [csirc@hhs.gov](mailto:csirc@hhs.gov).
 

DEVELOPMENT.md

@@ -1,6 +1,6 @@
 <!--- # NOTE: Modify sections marked with `TODO` and then rename the file.-->
 
-# Development and Software Delivery Lifecycle 
+# 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).
 
@@ -16,11 +16,11 @@ Each application has its own linting and testing guidelines. Lint and code tests
 
 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.
+- 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/worfklows](.github/workflows) directory.
 
@@ -69,26 +69,26 @@ All changes, including small ones, should have an issue. If they don't `[Hotfix]
 
 This project takes a very collaborative and [agile](https://agilemanifesto.org/) approach to code reviews. Working versions of code, self-organizing, and individuals are prioritized When reviewing pull requests:
 
-* **Be prompt**. Aim to respond to a review within 24 hours (although sooner is preferable), and if you cannot do so, be sure to communicate delays to the code author.
-* **Be kind and respectful** when leaving comments and maintain a collaborative tone. Don’t use language that disparages or embarrasses the author (name calling, insults to intelligence, etc). Direct any negative feedback towards the code rather than towards the author.
-* **Present suggestions as requests rather than demands**; instead of “Move this function to file B” try “Would this function fit better in file B?” This allows the author to push back on the suggestion by answering a question rather than rejecting a demand, which helps keep things from getting combative.
-* **Praise and compliment** the good parts!
-* **Explain suggestions and recommendations**. These should be opportunities for learning/mentoring, not for criticism or giving orders.
-* **Offer to chat in person** for more complex discussions, or to ensure understanding of new logic.
-* **Review the testing** as well as the code. You may think of edge cases or other things that the author’s testing plan might have missed.
-* **Clearly designate between required and optional changes**. This can take many forms, but as examples: “(optional) We might want to rename this variable to avoid confusion” and “(blocking) We don’t properly handle deadlocks here, so we’ll need to fix that.” It may also be helpful to clearly designate praises, questions, nits, etc to make a comment’s intention very clear.
-* Consider using **[conventional comments](https://conventionalcomments.org/)** for messages.
-* Use the **"Add a suggestion"** feature to suggest small changes in PRs.
-  
-![add a suggestion pop-up](https://github.com/HHS/grants-equity/assets/512243/e08efbd3-91de-43ce-a0d5-4529ccb1ac13)
-
-* **The "Request Changes"** feature *requires* the reviewer approve changes. This takes autonomy from the engineer, and should only be used if there is an urgent need.
+- **Be prompt**. Aim to respond to a review within 24 hours (although sooner is preferable), and if you cannot do so, be sure to communicate delays to the code author.
+- **Be kind and respectful** when leaving comments and maintain a collaborative tone. Don’t use language that disparages or embarrasses the author (name calling, insults to intelligence, etc). Direct any negative feedback towards the code rather than towards the author.
+- **Present suggestions as requests rather than demands**; instead of “Move this function to file B” try “Would this function fit better in file B?” This allows the author to push back on the suggestion by answering a question rather than rejecting a demand, which helps keep things from getting combative.
+- **Praise and compliment** the good parts!
+- **Explain suggestions and recommendations**. These should be opportunities for learning/mentoring, not for criticism or giving orders.
+- **Offer to chat in person** for more complex discussions, or to ensure understanding of new logic.
+- **Review the testing** as well as the code. You may think of edge cases or other things that the author’s testing plan might have missed.
+- **Clearly designate between required and optional changes**. This can take many forms, but as examples: “(optional) We might want to rename this variable to avoid confusion” and “(blocking) We don’t properly handle deadlocks here, so we’ll need to fix that.” It may also be helpful to clearly designate praises, questions, nits, etc to make a comment’s intention very clear.
+- Consider using **[conventional comments](https://conventionalcomments.org/)** for messages.
+- Use the **"Add a suggestion"** feature to suggest small changes in PRs.
+
+![add a suggestion pop-up](https://github.com/HHS/simpler-grants-gov/assets/512243/e08efbd3-91de-43ce-a0d5-4529ccb1ac13)
+
+- **The "Request Changes"** feature _requires_ the reviewer approve changes. This takes autonomy from the engineer, and should only be used if there is an urgent need.
 
 ## Releases
 
 Releases follow the [CalVer](https://calver.org/) versioning using a `YYY.MM.DD` format. Optionally include a `-N` if more than one releases are published in the same day.
 
-Releases should be [created in Github](https://github.com/HHS/grants-equity/releases) and include a log of changes.
+Releases should be [created in Github](https://github.com/HHS/simpler-grants-gov/releases) and include a log of changes.
 
 ## Documentation