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 - behavior related to user tasks, functions, or business processes
• Non-functional Criteria - non-functional conditions such as design standards or documentation
• Performance Criteria - 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.

Closing an Issue

An issue may be closed automatically via pull request or manually if the issue is no longer being pursued. When manually closing an issue, an explanation must be provided as a comment. If a team member disagrees with the issue's closure, then it may be re-opened with a new comment providing further explanation.

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