Section 5 Email to Applicant
- 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
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