bcgov / bcgov/foi-flow

Section 5 Email to Applicant

Open
#3,373 0 comments 0 reactions 0 assignees View on GitHub
incomplete AC Story
Dominant language
Python
Stars
8
Forks
2
Avg merge
14h 34m
Merged PRs (30d)
46

Description

* As an applicant
* I want a email when there is not enough information to open an FOI request
* so that the applicant can provide the information

**Assumptions & Scope**
What are the assumptions for this story?

We can use an email instead of a letter.

Section 5 is used when there is not enough information to move a request from Intake In Progress to Open.

Examples would be:

- A third party has made the request and not provided proof they can access the information

- We need clarification to understand the request

-

If information is not received in 20 days, the request will be Closed.
What is IN scope?

What is NOT in scope?

**Acceptance Criteria**

**Scenario 1: xxxxxx**
* GIVEN ... (you or your condition)
* WHEN ... (what you do)
* THEN ... (what you see)

**Scenario 2: xxxxxx**
* GIVEN ... (you or your condition)
* WHEN ... (what you do)
* THEN ... (what you see)

**Scenario 3: xxxxxx**
...

**Dependencies? What is the impact of this dependency? (If so, link dependency in the ticket, make it visible in a team´s backlog)**

**Validation Rules? (If yes, list here)**

**Design**
@xxx - please link the Design here

**Definition of Ready**

1. [ ] Is there a well articulated User Story?
2. [ ] Is there Acceptance Criteria that covers all scenarios (happy/sad paths)?
3. [ ] If there is a user interface, is there a design?
4. [ ] Does the user story need user research/validation?
5. [ ] Does this User Story needs stakeholder approval?
6. [ ] Design / Solution accepted by Product Owner
7. [ ] Is this user story small enough to be completed in a Sprint? Should it be split?
8. [ ] Are the dependencies known/ understood? (technical, business, regulatory/policy)
9. [ ] Has the story been estimated?

**Definition of Done**

1. [ ] Passes developer unit tests
2. [ ] Passes peer code review
3. [ ] If there's a user interface, passes UX assurance
4. [ ] Passes QA of Acceptance Criteria with verification in Dev and Test
5. [ ] Confirm Test cases built and succeeding
6. [ ] No regression test failures
7. [ ] Test coverage acceptable by Product Owner
8. [ ] Ticket ready to be merged to master or story branch
9. [ ] Developer to list Config changes/ Update documents and designs
10. [ ] Can be demoed in Sprint Review
11. [ ] Tagged as part of a Release
12. [ ] Feature flagged if required
13. [ ] Change Management activities done?

Contributor guide

Open the contributing guide

Research direction

No files, tests, or entry points are identified in the issue. Clarify the Section 5 workflow and acceptance criteria before locating the implementation; done should include the applicant email for insufficient information and closure after 20 days without a response.

Written by the indexing model from the issue text.

Assessment

Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.