Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create support ticket template #1749

Merged
merged 3 commits into from
Oct 24, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
76 changes: 76 additions & 0 deletions .github/ISSUE_TEMPLATE/support-ticket.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
name: Support Ticket
description: Support ticket for requesting help from Boost team
title: "[Support Ticket]: "
labels: ["support", "triage"]
body:
- type: checkboxes
attributes:
label: Boost component
description: Please select the boost component you are filing a bug for
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just so I understand, what is the rationale for having this option at all?

It will take very little time for us to label it once the issue is captured, not having it would reduce the barrier for capturing an issue, and we need to read through the issue to check it's labeled right in any case. No?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are multiple way to creating a support ticket. But, generally agreed upon industry standard is to collect some basic information to allow support engineers to provide an initial direction of investigation rather than asking same questions from the client/customer.
If we don't even collect which component would is impacted, then this template would be no different than slack conversations.
PS: There labels are not github labels.

options:
- label: boost daemon - storage providers
required: false
- label: boost client
required: false
- label: boost UI
required: false
- label: boost data-transfer
required: false
- label: boost index-provider
required: false
- label: booster-http
required: false
- label: booster-bitswap
required: false
- label: LID Database - Yugabyte/LevelDB
required: false
- label: boostd-data
required: false
- label: Other
required: false
- type: textarea
id: version
attributes:
label: Boost Version
render: text
description: Enter the output of `boost --version` and `boostd --version` if applicable.
placeholder: |
e.g.
Daemon: boostd version 0.0.1+git.b27fec5
Client: boost version 0.0.1+git.b27fec5
validations:
required: true
- type: textarea
id: Description
attributes:
label: Describe the problem
description: |
This is where you get to tell us what went wrong, when doing so, please try to provide a clear and concise description of the bug with all related information:
* What you were doing when you experienced the problem?
* Any *error* messages you saw, *where* you saw them, and what you believe may have caused them (if you have any ideas).
* What is the expected behaviour?
* For deal related problems, please include the deal logs from the boost UI.
validations:
required: true
- type: textarea
id: extraInfo
attributes:
label: Logging Information
render: text
description: |
Please provide detailed logs for the problem. You can get set log level control as per the below example:
* boostd: use `boostd log list` to get all log systems available and set level by `boostd log set-level`.
validations:
required: true
- type: textarea
id: RepoSteps
attributes:
label: Repo Steps
description: "Steps to reproduce the behavior if available"
value: |
1. Run '...'
2. Do '...'
3. See error '...'
...
validations:
required: false