Merge pull request #896 from GSA/895-update-issue-templates

updated github templates

.github/ISSUE_TEMPLATE/bug_report_form.yml

@@ -1,7 +1,7 @@
 ---
 name: Bug Report
 description: Use this form to create a new Bug Report
-labels: ["bug", "needs refinement"]
+labels: ["bug"]
 body:
   - type: markdown
     attributes:
@@ -11,12 +11,7 @@ body:
   - type: markdown
     attributes:
       value: >
-        This form will guide you through creating a new Bug Report.
-
-        Bug Reports are used to report when something isn't working as-expected given the current
-        state of the project.  Bug Reports are not for requesting new stuff that isn't supposed
-        to be a part of the project as it is -- they're not for Feature Requests.  For those,
-        consider a User Story.
+        Bug Reports are used to report when something isn't working as-expected given the current state of the project.
 
   - type: markdown
     attributes:
@@ -43,6 +38,6 @@ body:
     id: replicate
     attributes:
       label: How to replicate
-      description: "Please tell us how we can replicate the problem.  A step-by-step walk-through is most helpful."
+      description: "Please tell us how we can replicate the problem. A step-by-step walk-through and screencapture is most helpful."
     validations:
       required: true

.github/ISSUE_TEMPLATE/config.yml

@@ -1,2 +1,2 @@
 ---
-blank_issues_enabled: true
+blank_issues_enabled: false

.github/ISSUE_TEMPLATE/task_form.yml

@@ -1,7 +1,7 @@
 ---
 name: Task
 description: Use this form to create a new Tasks
-labels: ["task", "needs refinement"]
+labels: ["task"]
 body:
   - type: markdown
     attributes:
@@ -11,22 +11,8 @@ body:
   - type: markdown
     attributes:
       value: >
-        This form will guide you through creating a new Task.
-
-        Tasks are like User Stories, but are generally written from the
-        perspective of a member of the team, often to describe something
-        that needs to be done that users wouldn't see.  User Stories
-        describe requirements -- the what -- while Tasks describe
-        implementation -- the how.
-
-        Tasks, like User Stories, should be narrow, but not shallow;
-        they should have focus that is executable and scope-bound.
-
-        Typically, Tasks are designed to be something that can be done
-        in a single day (but more than a few minutes worth of work).
-
-        Often, Tasks are associated with and/or make reference to
-        User Stories.  It's also common for the Definition of Done
+        Tasks are associated with and/or make reference to
+        User Stories. It's also common for the Definition of Done
         (DoD) from a User Story (the what) to be the starting point
         for Tasks (the how).
 
@@ -39,7 +25,7 @@ body:
     id: description
     attributes:
       label: Description
-      description: The Description is the verbiage that describes the work that needs to be done
+      description: What work needs to be done.
     validations:
       required: true
 
@@ -57,9 +43,9 @@ body:
       required: false
 
   - type: textarea
-    id: adrs
+    id: acceptance
     attributes:
-      label: Architectural Decision Records (ADRs)
-      description: "If any Architectural Decision Records (ADRs) are relevant to the execution of this Task, please reference them here"
+      label: Acceptance Criteria
+      description: "If any acceptance criteria are relevant to the execution of this task, please reference them here"
     validations:
       required: false

.github/ISSUE_TEMPLATE/user_story_form.yml

@@ -1,7 +1,7 @@
 ---
-name: User Story
-description: Use this form to create a new user story
-labels: ["story", "needs refinement"]
+name: Feature Request
+description: Use this form to create a new feature request
+labels: ["story"]
 body:
   - type: markdown
     attributes:
@@ -11,33 +11,26 @@ body:
   - type: markdown
     attributes:
       value: >
-        This form will guide you through creating a new [user story](https://www.agilealliance.org/glossary/user-stories/).
-
-        User stories capture requests and word them in terms of a persona
-        who may be making the request, the nature of their request, and
-        why the request adds value to the project.
+        This form will guide you through creating a new feature request by proposing a [user story](https://www.agilealliance.org/glossary/user-stories/).
 
+  - type: markdown
+    attributes:
+      value: >
         User stories capture **what** a user wants, not **how** they want
-        it done.  They capture goals, not system interactions.
+        it done.
 
-        A good user story is as small as possible as long as it:
+  - type: markdown
+    attributes:
+      value: >
+        User stories capture **what** a user wants, not **how** they want
+        it done.
 
           - Describes a user’s goal (what), not a system interaction (how)
           - Is narrow, rather than shallow
           - Is potentially shippable -- it can be experienced, is
             understandable, a user could make use of it
           - Is option-enabling - doesn’t specify implementation details
 
-        We write stories in this way so we can do the work in thin vertical
-        slices.  This results in little to no surprises by going through all
-        the layers. Rather than trying to do all of the research and then
-        all of the design, etc, you do just enough of each layer in order
-        to have something tangible that you can demo & build upon.
-
-        Think about what is the simplest path from beginning to end.  It’s
-        a basic user path, a happy path.  Think about the type of user
-        and what they would want to do.
-
   - type: markdown
     attributes:
       value: |
@@ -47,47 +40,31 @@ body:
     id: persona
     attributes:
       label: User / Persona
-      description: 'A user story is viewed from the perspective of a user or persona, such "survey administrator" or "software engineer"'
+      description: 'A user story is viewed from the perspective of a user or persona, such "content editor" or "user approaching retirement".'
       placeholder: "(who) As a..."
     validations:
       required: true
   - type: input
     id: reason
     attributes:
       label: Reason / Justification
-      description: 'Finally, a user story involves a reason or a justification as to why the story should be completed -- an answer to "why should we do this?"'
+      description: "Why the story should be completed."
       placeholder: "(why) so that...."
     validations:
       required: true
-  - type: input
-    id: request
-    attributes:
-      label: Request
-      description: "Next, a user story includes the request; note: here we share what we want, not how we want it done"
-      placeholder: "(what) I want..."
-    validations:
-      required: true
 
   - type: markdown
     attributes:
       value: |
         ## Optional fields
-  - type: textarea
-    id: dod
-    attributes:
-      label: Definition of Done (DoD)
-      description: The Definition of Done is a list of criteria under which the team would consider this story complete; may include references to issues
-      value: "- [ ] "
-    validations:
-      required: false
   - type: textarea
     id: ac
     attributes:
       label: Acceptance Criteria (AC)
-      description: The Acceptance Criteria are a series of tests meant to confirm that things are working as-expected
+      description: A list of criteria under which the team would consider this story complete; may include references to issues.
       value: "- [ ] "
     validations:
-      required: false
+      required: true
   - type: textarea
     id: other
     attributes:

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,14 +1,14 @@
 ## PR Summary
 
-Include a summary of the change, relevant motivation, and context.
+<!--- Include a summary of the change, relevant motivation, and context. -->
 
 ## Related Github Issue
 
 - fixes #(issue)
 
 ## Detailed Testing steps
 
-Link to testing steps in the issue or list them here:
+<!--- Link to testing steps in the issue or list them here -->
 
 - [ ] Testing step 1
 - [ ] Testing step 2

.gitignore

@@ -53,3 +53,6 @@ web/modules/custom/bixal_uswds_general
 backups/*.sql.gz
 *.Identifier
 *.gz
+
+# VSCode
+.vs