##// END OF EJS Templates
login: Make register views more robust if some POST parameters are missing....
login: Make register views more robust if some POST parameters are missing. We fail to delete passsword/password confirm parameters if they are not part of the POST parameters. But failing to delete them if they are not present seems wrong. Better silently ignore if they are not present.

File last commit:

r303:ed619a55 default
r1065:64aae6b3 default
Show More
checklist-tickets.rst
137 lines | 3.5 KiB | text/x-rst | RstLexer

Ticket Checklists

Ticket Description

In general these things really matter in the description:

  • Reasoning / Rationale. Explain "WHY" it makes sense and is important.

  • How to reproduce. Easy to follow steps, that’s important.

    • Observation: The problem (short)
    • Expectation: How it should be (short)
  • Specs: It is fine to draft them as good as it works.

    If anything is unclear, please ask for a review or help on this via the Community Portal or Slack channel.

Checklists for Tickets

BUG

Definition: An existing function that does not work as expected for the user.

  • Problem description
  • Steps needed to recreate (gherkin)
  • Link to the screen in question and/or description of how to find it via navigation
  • Explanation of what the expected outcome is
  • Any hints into the source of the problem
  • Information about platform/browser/db/etc. where applicable
  • Examples of other similar cases which have different behaviour

DESIGN

Definition: Styling and user interface issues, including cosmetic improvements or appearance and behaviour of frontend functionality.

  • Screenshot/animation of existing page/behaviour
  • Sketches or wireframes if available
  • Link to the screen in question and/or description of how to find it via navigation
  • Problem description
  • Explanation of what the expected outcome is
  • Since this may be examined by a designer; it should be written in a way that a non-developer can understand

EPIC

Definition: A collection of tickets which together complete a larger overall project.

  • Benefit explanation
  • Clear objective - when is this complete?
  • Explanations of exceptions/corner cases
  • Documentation subtask
  • Comprehensive wireframes and/or design subtasks
  • Links to subtasks

FEATURE

Definition: A new function in the software which previously did not exist.

  • Benefit explanation
  • Clear objective
  • Explanations of exceptions/corner cases
  • Documentation subtask
  • Comprehensive wireframes and/or design subtasks

SUPPORT

Definition: An issue related to a customer report.

  • Link to support ticket, if available
  • Problem description
  • Steps needed to recreate (gherkin)
  • Link to the screen in question and/or description of how to find it via navigation
  • Explanation of what the expected outcome is
  • Any hints into the source of the problem
  • Information about platform/browser/db/etc. where applicable
  • Examples of other similar cases which have different behaviour

TASK

Definition: An improvement or step towards implementing a feature or fixing a bug. Includes refactoring and other tech debt.

  • Clear objective
  • Benefit explanation
  • Links to parent/related tickets

All details below.

External links:

  • Avoid linking to external images; they disappear over time. Please attach any relevant images to the ticket itself.
  • External links in general: They also disappear over time, consider copying the relevant bit of information into a comment or write a paragraph to sum up the general idea.

Hints

Change Description

It can be tricky to figure out how to change the description of a ticket. There is a very small pencil which has to be clicked once you see the edit form of a ticket.

Example of pencil to change the ticket description

Shows an example of the pencil which lets you change the description.