Evaluation forms list

[r-bartlett-gsa]

User story

As a challenge manager, in order to manage all my evaluation forms efficiently, I would like to be able to review them in the list view and understand what the forms are for, and what actions I can take.

Acceptance Criteria:

• [ ] The challenge manager can navigate to a list of evaluation forms via the dashboard or utility nav
• [ ] If the user does not have any saved (draft or published) evaluations forms, the list is empty
  • [ ] The user can start the process for creating a new evaluation form from this page
• [ ] If the user has saved (draft or published) evaluations forms, the list of evaluation forms displays:
  • [ ] Evaluation form name
  • [ ] Challenge name the form is assigned to (if any)
  • [ ] Evaluation form status (draft or published)
• [ ] The user can choose the following options:
  • [ ] View by clicking on the title of the form, #61
  • [ ] Edit (if the form is in draft status), #61
  • [ ] Delete (if the form is in draft status), #63
  • [ ] Post-MVP: Clone (for any status), #62
  • [ ] Post-MVP: Preview
• [ ] From the list view, the user can select to create a new evaluation form, #61

Development tasks:

• [ ] #129
• [ ] #130

Definition of Done

Doing (dev team)

• [ ] Code complete
• [ ] Code is organized appropriately
• [ ] Any known trade offs are documented in the associated GH issue
• [ ] Code is documented, modules, shared functions, etc.
• [ ] Automated testing has been added or updated in response to changes in this PR
• [ ] The feature is smoke tested to confirm it meets requirements
• [ ] Database changes have been peer reviewed for index changes and performance bottlenecks
• [ ] PR that changes or adds UI
  • [ ] include a screenshot of the WAVE report for the altered pages
  • [ ] Confirm changes were validated for mobile responsiveness
• [ ] PR approved / Peer reviewed

• [ ] Move card to testing column in the board

  Testing (dev team)

• [ ] Security scans passed
• [ ] Automate accessibility tests passed
• [ ] Build process and deployment is automated and repeatable
• [ ] Feature toggles if appropriate
• [ ] Deploy to staging

Staging

• [ ] Accessibility tested (Marni)
  • [ ] Keyboard navigation
  • [ ] Focus confirmed
  • [ ] Color contrast compliance
  • [ ] Screen reader testing
• [ ] Usability testing: mobile and desktop (Tracy or Marni)
• [ ] Cross browser testing (tool to be determined) (Tracy or Marni)
  • [ ] UI rendering is performant
• [ ] AC review (Renata)
• [ ] Deploy to production (production-like environment for eval capability) (dev team)

• [ ] Move to production column in the board

  Production

• [ ] User and security documentation has been reviewed for necessary updates (Renata/Tracy/Dev team)
• [ ] PO / PM approved (Jarah or Renata)
• [ ] AC is met and it works as expected (Jarah or Renata)
• [ ] Move to done column in the board (Jarah or Renata)

[r-bartlett-gsa]

[stepchud]

I think there will be a lot of chicken/egg type problems like this, but I'm wondering purely from execution perspective how can we plan for delivering this in stages, i.e. without having the full functionality of the page and all the form cards implemented.

[stepchud]

How does the user navigate here? Can we add that to the ticket?

[r-bartlett-gsa]

How does the user navigate here? Can we add that to the ticket?

@stepchud The user navigates to here from here: https://github.com/GSA/Challenge_platform/issues/53

[r-bartlett-gsa]

I think there will be a lot of chicken/egg type problems like this, but I'm wondering purely from execution perspective how can we plan for delivering this in stages, i.e. without having the full functionality of the page and all the form cards implemented.

@stepchud Let's discuss this. I broken down the user stories so they can be delivered in stages, but if that does not address your concern I would like to learn more. Also, I realize that there will be parts/sections that we will need to come back to, after we implement something else, I think that's a normal part of the process.