Skip to content

A repo to hold labels used by CATcher (for reference)

Notifications You must be signed in to change notification settings

CATcher-org/templates

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

33 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Issue Templates

Bug Reporting Phase

[App] Collect Bug Reports

  • Title and body as the tester entered.
  • Labels: severity.*, type.* (both compulsory)

[Script S1a] Tester-Repo → Interim-Repo

Note: issue title remains the same as the original issue, throughout the workflow

Issue body:

{original issue description}

<hr>
<sub>[original: username/interim-repo-name#issue-number]</sub>

Example:

The app doesn't work


[original: johnDoe/pe#1234]

Notes:

  • Only open issues are to be transferred.
  • Copy the severity.* label. If no severity label, apply severity.Low
  • Copy the type.* label.
  • Transfer image files to the settings repo (public) and update the link in the issue body.
  • Check the timestamp. Only bugs reported within the PE period should be transferred. Add a comment to issues falling outside the accepted time window.

    Bug report not accepted as it was modified outside the time window {start time}-{end time}

[Script S1b] Interim-Repo → Dev-Repo

Body:

{issue description: same as interim}

<hr>
<sub>[original: module-org/interim-repo-name#issue-number]</sub>

Notes:

  • Copy all labels
  • Apply the correct tutorial.* label and team.* label to indicate the receiving team

[Script S1c] In the dry run: Tester-Repo → Team-Repo

  • Transfer the bug report to the respective team repo.
  • Labels are to be omitted.
  • Image links can be kept as they are

Dev Response Phase

[App] Collect Dev Response

Body:

{same as interim repo}

Add a comment:

# Team's Response

{team's response}

## Duplicate status (if any):
Duplicate of #{issue-number}

Example:

Team's Response

Yes, we missed this. But it's a minor bug.

Duplicate status (if any):

Duplicate of #1234

Labels: severity.*, type.*, response.*, duplicate

[Script S2] Dev-Repo → Tester-Repo

Add a comment to the original issue in tester/repo-name, in the following format:

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

# Team's Response

{team's response}

# Items for the Tester to Verify
## :question: {type of verification}

{description}

- [ ] I disagree

**Reason for disagreement:**
[replace this with your reason]

<catcher-end-of-segment><hr>

Example:

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

Description of team's response

Items for the Tester to Verify

❓ Issue response

Team chose [response.Rejected].

  • I disagree

Reason for disagreement: [replace this with your reason]


❓ Issue severity

Team chose [severity.Low].

Originally [severity.High].

  • I disagree

Reason for disagreement: [replace this with your reason]


❓ Issue type

Team chose [type.DocumentationBug].

Originally [type.FunctionalityBug].

  • I disagree

Reason for disagreement: [replace this with your reason]


Notes:

  • If the issue is a duplicate, it should be considered as using severity, type, and response from the "original" issue.
  • If the response.* is missing, add response.Accepted to the destination issue (not the source issue).
  • If the dev response contains images, they need to be transferred to the settings repo as well
  • How to find the original issue? embed an encrypted string in the issue? Alternatively, can trace back via the interim repo.

Tester Response Phase

[App] Collect Tester Response

Update the comment. Example:

❓ Issue type

Team chose [type.DocumentationBug].

Originally [type.FunctionalityBug].

  • I disagree

Reason for disagreement: It's a bug, not a typo.


[Script S3] Tester-Repo → Tutor-Repo

Body:

# Issue Description
{original issue description}

# Team's Response
{team's response}

# Disputes

## :question: {type of verification}

### Team says:
{the team's action that is being disputed}

### Tester says:
{tester's objection}

Example:

...

Disputes

❓ Issue type

Team says:

Team chose [type.DocumentationBug].

Originally [type.FunctionalityBug].

Tester says:

I think it a functionality bug. The feature doesn't work. It's nothing to do with docs.

  • Labels to be copied from the dev-response repo: type, severity, response, tutorial, team
  • The script will also generate a label based on the number of Disputes (e.g pending.2 for issue with two disputes)

Moderation Phase

[App] Collect Tutor Response

  • Show ticks for each dispute
  • Add a comment to record tutor response
# Tutor Moderation

## {type of verification}

{tutor explanation}

Example:

Tutor moderation

❓ Issue severity

  • Done

I think it is justified.

❓ Issue type

  • Done

Not justified. I've changed it back.

  • Allow tutor to change other labels
  • The pending.x label will be removed if all tasks are done
  • Allow adding an Unsure label, in case the tutor is unsure about the decision

About

A repo to hold labels used by CATcher (for reference)

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published