Issues

What is an Issue?

An issue represents a proposed change to the project's code base.

Issue Templates

Issue templates provide predefined sections for the two most common types of change requests:

1. Bug report - a description of existing functionality that is not working as expected
2. Feature request - a description of new functionality that does not yet exist

Issue Title

<type>: <subject line>

Each issue title should include a prefix with <type>: followed by a <subject line>.

Issue Title Examples

• chore: add JS sourcemaps
• doc: improve clarity of DocBlocks
• feat: add summary report for all forms
• format: apply WordPress Coding Standards
• fix: prevent white screen after donation

User Story

Each issue starts with a user story that communicates the goal from the perspective of specific type of user. Every user story includes three key elements formatted as follows:

As a <type of user>, I want <some goal> so that <some reason>.

User Story Examples

• As a donor, I want Apple Pay support so that I can complete mobile transactions faster.
• As an accountant, I want to export quarterly donations so I can import them into bookkeeping software.
• As a developer, I want to disable CSS so I can provide my own custom styles.

Acceptance Criteria

A great issue proposes a change and defines the conditions necessary to accept that change. These conditions, known as acceptance criteria, must be true in order to accept the change and close the issue. There is no partial acceptance; either a criterion is met or it is not.

• Acceptance criteria DO clearly define the conditions of satisfaction.
• Acceptance criteria DO NOT prescribe solutions to achieve these conditions.

Types of Acceptance Criteria

Each issue may contain one or more types of acceptance criteria:

• Functional Criteria - identify behavior related to user tasks, functions, or business processes
• Non-functional Criteria - identify non-functional conditions such as design standards or documentation
• Performance Criteria - identify performance-related conditions that must be true

Acceptance Criteria Examples

• Something happens when an action is taken.
• Something does not happen when an action is taken.
• Fixing behavior in Component A does not affect existing behavior in Component B.

DO

1. Begin each issue title with a <type>: prefix.
2. Use the imperative mood.
3. Wrap any code, such as Class_Name, method(), $property, $variable, or @tag, in backticks.
4. Write goal-oriented issue titles. Think about the problem that needs solved and turn it into a goal.
5. Assign each issue an estimate of story points based on complexity. This number can be updated once the issue is better understood. Issues with unknown complexity should be assigned 3 story points to start.
6. Follow the issue template within reason, removing optional sections that do not apply.

DO NOT

1. Do not end issue titles with a period.
2. Do not exceed 50 characters in issue title.
3. Do not include multiple goals in a single issue.

Roles & Capabilities

• Support/Marketing/Community
  • Add issue
  • Add label
• Development
  • Add issue
  • Add label
  • Add estimate
• Senior Development
  • Add issue
  • Add label
  • Add estimate
  • Add assignee
  • Add to sprint (milestone)
  • Add to release
  • Add to epic