Merge pull request #33 from asteel-gsa/as/test-2

PR checks test

.github/ISSUE_TEMPLATE/onboarding.md

@@ -59,7 +59,7 @@ Here's a checklist to get you started and to make sure you've got access to :all
 - [ ] Familiarize yourself with Python, Django, and Cloud.gov—all tools used in this project.
   - [ ] If you need to catch up on the latest in Python development, check out the [Python developer's guide](https://devguide.python.org/).
   - [ ] Work through the [Django Tutorial](https://docs.djangoproject.com/en/4.0/intro/tutorial01/) and writing your first Django app.
-  - [ ] If it's not already set up on your machine & account, enable [commit signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). Also see the pinned messages in the Slack development channel. (test)
+  - [ ] If it's not already set up on your machine & account, enable [commit signing](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). Also see the pinned messages in the Slack development channel.
   - [ ] If you're not already, get [setup with Cloud.gov](https://cloud.gov/docs/getting-started/setup/)
     - [ ] Once your account exists, make a PR to [add yourself to the list of developers](https://github.com/GSA-TTS/FAC/tree/main/terraform/meta/config.tf) with access to our spaces.
   - [ ] Practice deploying a [python application](https://github.com/cloud-gov/cf-hello-worlds/tree/main/python-flask) to Cloud.gov using the Cloud.gov command line interface (CLI): https://cloud.gov/docs/getting-started/your-first-deploy/.

backend/manage.py

@@ -2,6 +2,7 @@
 """Django's command-line utility for administrative tasks."""
 import os
 import sys
+import time
 
 
 def main():

docs/agile-process.md

@@ -1,27 +1,27 @@
-Agile Process
+Agile Process (test)
 ===================
 
 ### About this document
-This document defines the workflow-level execution process for the team. The related [team charter document](https://app.mural.co/t/gsa6/m/gsa6/1657921027860/f6d15b9a5882fb0615078010bacc5dd4826c0130?invited=true&sender=ua4d37dfba3f1e69e09078790) is a more personal document that introduces the team members and what they do on the team, core values and group norms. 
+This document defines the workflow-level execution process for the team. The related [team charter document](https://app.mural.co/t/gsa6/m/gsa6/1657921027860/f6d15b9a5882fb0615078010bacc5dd4826c0130?invited=true&sender=ua4d37dfba3f1e69e09078790) is a more personal document that introduces the team members and what they do on the team, core values and group norms.
 
 ### Overview
 
-There is a [high-level roadmap](https://github.com/GSA-TTS/FAC/blob/main/docs/product/roadmap.md) containing Milestones that the product and design team distills down to actionable tasks at the beginning of each sprint. Design, engineering and product work is tracked on the [FAC Task Tracking board](https://github.com/GSA-TTS/FAC/projects/1) in Github with corrosponding roadmap Milestones. 
+There is a [high-level roadmap](https://github.com/GSA-TTS/FAC/blob/main/docs/product/roadmap.md) containing Milestones that the product and design team distills down to actionable tasks at the beginning of each sprint. Design, engineering and product work is tracked on the [FAC Task Tracking board](https://github.com/GSA-TTS/FAC/projects/1) in Github with corrosponding roadmap Milestones.
 
 ### Creating issues
- 
+
 **Story** - Issues of this type define high-level pieces of functionality that may require multiple team members to implement (design, front-end, back-end engineering, etc). These currently use the "Story template". The "story" label is added to this. Often sub tasks will be created and linked from stories. The person assigned the story is considered the "shepherd" of the issue who is tasked with tying it all together.
- 
+
 **Task** - Issues of this type represents a discrete piece of functionality that should not require more than one day of work. It should use the "Basic task tracking" template that links back to the main story and has specific acceptance criteria. Tasks are given a "design" or "engineering" label.
- 
+
 **Ceremonies** - The goal is for new work from the backlog to enter the sprint at the start of the sprint and have agreement from the team that it's realistic to get the body of work done by the end of the sprint. In practice, items are sometimes removed and added to the sprint while it's ongoing. When this happens, team members are expected to communicate the up-scope or down-scope of the sprint to the rest of the team. Items that the team agrees to take on from the outset are currently given a sprint milestone, which communicates what the team anticipated was possible.
- 
-**Labeling issues** - In addition to the "story", "design" and "engineering" labels, the "needs refinement" label is a very important label to denote whether an issue needs to be better clarified. There are a bunch of other labels that are rarely used and could probably be deleted. These two carry special significance since we try not to actively work on an issue until these labels have been removed: 
+
+**Labeling issues** - In addition to the "story", "design" and "engineering" labels, the "needs refinement" label is a very important label to denote whether an issue needs to be better clarified. There are a bunch of other labels that are rarely used and could probably be deleted. These two carry special significance since we try not to actively work on an issue until these labels have been removed:
 
 * “Needs refinement” - need a design, engineering or product decision to move forward
-* “Needs scoping” - needs people to pair up and review, then break down an issue into individual tasks and estimate them using beverage sizes. Assuming this is an engineering story, they will put another beverage size on the story level which will be used to determine capacity through an eyeball, non-mathematical judgement. 
+* “Needs scoping” - needs people to pair up and review, then break down an issue into individual tasks and estimate them using beverage sizes. Assuming this is an engineering story, they will put another beverage size on the story level which will be used to determine capacity through an eyeball, non-mathematical judgement.
+
 
-
 **Estimation / Velocity** - There is no estimation process for tickets, but they should be refined to be in approximately comparable sizes. The team works in two-week sprints starting on Tuesdays. As of right now, our two velocity metrics are number of tasks completed and number of stories completed in a sprint tracked
 
 ### Board workflow
@@ -38,24 +38,24 @@ There is a [high-level roadmap](https://github.com/GSA-TTS/FAC/blob/main/docs/pr
 
 - **Done (Sprint X)** - The path to "Done" varies by issue type:
 
-    - **User Story** - Acceptance criteria for a task is verified by PM or QA lead on the development instance, then moved to done. 
+    - **User Story** - Acceptance criteria for a task is verified by PM or QA lead on the development instance, then moved to done.
 
-    - **Engineering task** - Acceptance criteria is verified by an engineer on the development instance, then moved to done. 
+    - **Engineering task** - Acceptance criteria is verified by an engineer on the development instance, then moved to done.
 
-    - **Design task** - PM verifies the process for next steps / implementation is documented in another ticket, then moved to done. 
+    - **Design task** - PM verifies the process for next steps / implementation is documented in another ticket, then moved to done.
 
-    - **Product task** - PM asks relevant parties (design, engineering, etc) to review and move to done.  
+    - **Product task** - PM asks relevant parties (design, engineering, etc) to review and move to done.
 
 Note: Sprint-specific "done" columns are used to track exactly what was completed in a current sprint for velocity / reporting purposes.
 
 ### Quality assurance
 
-As of the time of this writing, the product manager does the following QA on each story before moving to done: 
+As of the time of this writing, the product manager does the following QA on each story before moving to done:
 
 - [ ] Meets acceptance criteria
 - [ ] Screen reader - Listen to the experience with a screen reader extension, ensure the information presented in order
-- [ ] Keyboard navigation - Run through acceptance criteria with keyboard tabs, ensure it works. 
-- [ ] Text scaling - Adjust viewport to 1280 pixels wide and zoom to 200%, ensure everything renders as expected. Document 400% zoom issues with USWDS if appropriate. 
+- [ ] Keyboard navigation - Run through acceptance criteria with keyboard tabs, ensure it works.
+- [ ] Text scaling - Adjust viewport to 1280 pixels wide and zoom to 200%, ensure everything renders as expected. Document 400% zoom issues with USWDS if appropriate.
 
 ### How we'll stay on track
 
@@ -70,21 +70,21 @@ Time-based estimations are prone to inaccuracy and preconceived notions of "how
 # Supporting Meetings and processes
 
 ### Standup
-We do standups on video chat, but everyone has the option to do it in Slack instead. 
+We do standups on video chat, but everyone has the option to do it in Slack instead.
 
 ### Sprint planning (Backlog->Available)
 
-At the start of each sprint, we review the stories refined for implementation and ensure they are of sufficient definition and priority. We aim to take on work that can be completed within one sprint. If a story seems like it'll need to span more than one sprint, that may be a sign that it needs to be broken into a smaller chunk of work. 
+At the start of each sprint, we review the stories refined for implementation and ensure they are of sufficient definition and priority. We aim to take on work that can be completed within one sprint. If a story seems like it'll need to span more than one sprint, that may be a sign that it needs to be broken into a smaller chunk of work.
 
-All teams members to provide update in github issues in progress on Monday/early-Tues before sprint planning and backlog refinement. 
+All teams members to provide update in github issues in progress on Monday/early-Tues before sprint planning and backlog refinement.
 
 ### Code Review (In Progress->Ready For Review->Done)
 
 Pull requests are reviewed on a per-ticket basis and tests are automatically run on the CI server. Approval from one reviewer is required to merge a pull request. Reviewer is welcome to merge but responsibility to merge is with the submitter. Signal to the team in slack if you've waited more than two hours for a review.
 
 ### Quality Assurance
 
-Stories are QA'ed against acceptance criteria (AC) with test coverage, including our manual accessibility checklist: 
+Stories are QA'ed against acceptance criteria (AC) with test coverage, including our manual accessibility checklist:
 
 * Screen reader - Listen to the experience with a screen reader extension, ensure the information presented in order
 * Keyboard navigation - Run through acceptance criteria with keyboard tabs, ensure it works.
@@ -108,4 +108,4 @@ Elaboration includes:
 
 -   Acceptance criteria
 
--   Latest mocks
+-   Latest mocks