chore: adding organization wide issue template#7
Conversation
theproducer
changed the title
OS-pedrogustavobilro
left a comment
OS-pedrogustavobilro
left a comment
There was a problem hiding this comment.
I'm adding some comments. I'm unsure if they were already asked before in other contexts, so apologies in advance if you're getting duplicate comments 🙏
| ## Thanks for taking the time to fill out this bug report! | ||
| Before creating a bug report, be sure to keep the following points in mind: | ||
| - Search existing reports to make sure there isn't already an existing bug report. | ||
| - Make sure this is the correct project for your report. If the report is related to a plugin or Capacitor core, create the bug report on that GitHub project instead. |
There was a problem hiding this comment.
What do you mean by "If the report is related to a plugin or Capacitor core, create the bug report on that GitHub project instead"?
Are you meaning to say, if you're having an issue with a plugin, open in the appropriate GitHub repo for the plugin, instead of Capacitor?
| - type: checkboxes | ||
| id: versions-affected | ||
| attributes: | ||
| label: Versions Affected | ||
| description: "Check the versions that this bug is related to." | ||
| options: | ||
| - label: 7.x | ||
| required: false | ||
| - label: 8.x | ||
| required: false | ||
| - label: 9.x | ||
| required: false |
There was a problem hiding this comment.
These versions vary according to the repo no? How can it be re-used / configured?
| validations: | ||
| required: false |
There was a problem hiding this comment.
Shouldn't we requirereproduction for bug reports? Don't know how insistent we want to be on it, but would it maybe reduce the number of issues opened without reproduction?
| description: "Please provide the following information with your request and any other relevant technical details (versions of IDEs, local environment info, plugin information or links, etc)." | ||
| placeholder: | | ||
| OS version: | ||
| `npx cap doctor` output: | ||
| npm --version output: | ||
| node --version output: | ||
| pod --version output (iOS Cocoapods issues only): | ||
| render: Shell | ||
| validations: | ||
| required: false |
There was a problem hiding this comment.
Shouldn't env-details be required as well? There can be cases where it might not matter, but to me it's better to request more info at first than having to request it afterwards? If that makes sense.
| label: Expected Behavior | ||
| description: "Describe what you expected to happen, or what should be the correct behavior." | ||
| validations: | ||
| required: true |
There was a problem hiding this comment.
What about current or obtained behavior? Would that be in description? In my head we'd have both those fields next to each other, to be able to succinctly understand what's the expectation vs reality.
| - label: Android | ||
| required: false | ||
| - label: Web | ||
| required: false |
There was a problem hiding this comment.
Is this configurable by the consuming repos? I reckon for Capacitor we'd want to have this information required, but if we want to use it across all our ionic-team repositories, in native libraries this information is irrelevant.
| id: description | ||
| attributes: | ||
| label: Description | ||
| description: "Give a detailed explanation of the bug you've encountered." |
There was a problem hiding this comment.
Should we go into more information into what we're looking for here? I don't if we can get into specifics on what we're looking for in the description, because it can vary a lot per issue. Just thinking if we can add any more info here that can help people that may be opening a bug report for the first time in our repos.
2 participants
No description provided.