Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

What should be included?

  • Background/rationale
    • The context of the changes being made
    • E.g. if it’s a bug, who reported it, when, and under what circumstances.
      • What is the root-cause of the bug?
      • What is the solution implemented here?
      • Is a longer-term solution still required?
      Feature requests probably need a bit more background, with info about where the request came from, copies/links to any discussions about implementation, etc.
  • Changes
    • Sometimes just a list of commit messages
    • Usually more useful to base on commit messages, but removing useless messages (like “fixed style of new code”) and expanding on important commits.
  • Relevant links
    • Jira tickets, Confluence pages, related issues in other projects etc.

Template/example

## Types of changes
* [ ]  Bug fix (a non-breaking change which fixes an issue)
* [x]  New feature (a non-breaking change which adds functionality)
* [ ]  Breaking change (fix or feature that would cause existing functionality to change)

## Background
E.g. Resolves [Add WorkItem list status filter](https://jira.ukrdc.org/browse/UI-10)
Allows searching for work items for different status values by adding a filter to the workitem list UI

## Changes
* All changes confined to `pages/workitems/index.vue`
* Adds filter interface to the component template.
* Adds filter logic to component script.

## Relevant links
* [Add WorkItem list status filter](https://jira.ukrdc.org/browse/UI-10)
  • No labels