Add issue templates #62
Conversation
{{cookiecutter.project_name}}/.github/ISSUE_TEMPLATE/bug_report.yml
Outdated
Show resolved
Hide resolved
{{cookiecutter.project_name}}/.github/ISSUE_TEMPLATE/bug_report.yml
Outdated
Show resolved
Hide resolved
|
I think we agreed to stick with the simple, explicit version placeholder for now. |
| - type: textarea | ||
| id: description | ||
| attributes: | ||
| label: Description of the bug | ||
| description: A clear and concise description of what the bug is. | ||
| validations: | ||
| required: true | ||
|
|
||
| - type: textarea | ||
| id: repex | ||
| attributes: | ||
| label: Minimal reproducible example | ||
| description: A code snipped that we can copy&paste to reproduce the bug without having any data | ||
| render: python | ||
| placeholder: | | ||
| import scanpy as sc | ||
| adata = sc.datasets.pbmc3k() | ||
|
|
||
| sc.do_something_that_doesnt_work(adata) | ||
|
|
||
| - type: textarea | ||
| id: stacktrace | ||
| attributes: | ||
| label: The error message produced by the code above | ||
| description: Please paste the entire error message | ||
| render: pytb | ||
| placeholder: | | ||
| --------------------------------------------------------------------------- | ||
| AssertionError Traceback (most recent call last) | ||
| <ipython-input-5-78750baef17a> in <module> | ||
| ----> 1 adata = sc.do_something_that_doesnt_work(adata) | ||
|
|
||
| /opt/conda/lib/python3.8/site-packages/scanpy/_preprocessing.py in do_something_that_doesnt_work(adata) | ||
| 438 | ||
| --> 439 raise AssertionError("Demo function that fails") | ||
| 440 |
There was a problem hiding this comment.
I'm not sure this is a lot better than just having free-form markdown.
While many bug reports fit "ran this code, got this error" not all do. Especially difficult to solve ones. How does "incorrect thing works" or "this works, this works, this doesn't" fit into this template?
There was a problem hiding this comment.
All fields except for the first one are optional and you can write free-form markdown there.
There was a problem hiding this comment.
My preference here would be:
One required field with description of bug. This includes a template that looks like:
## Description
## Example
```python
import {pkg}
# Minimal example to reproduce bug
````
```pytb
# Traceback from running code
```
And a required field for version info.
To me, Text, Code block, Error block may be the most common bug report format, but I'm not sure it's over 50% prevalence. I think putting too much structure here makes it harder for people to report, since they'll try to fit their problem into structure.
|
A PR has been generated to the instance repo: You can check out the PR to preview your changes |
{{cookiecutter.project_name}}/.github/ISSUE_TEMPLATE/bug_report.yml
Outdated
Show resolved
Hide resolved
{{cookiecutter.project_name}}/.github/ISSUE_TEMPLATE/bug_report.yml
Outdated
Show resolved
Hide resolved
| dependencies = ["anndata"] | ||
| dependencies = [ | ||
| "anndata", | ||
| # for debug logging (referenced from the issue template) |
There was a problem hiding this comment.
| # for debug logging (referenced from the issue template) |
…t.yml Co-authored-by: Giovanni Palla <[email protected]>
|
By now, I tend to side with @ivirshup: Rather have a less-structured bug report form - I think it's still better to receive low quality bug reports than not receiving any. But a markdown template within an issue form is also ugly. Maybe just make it very explicit in the forms description which fields are optional? (or no template at all: This is fine for most repos until you reach a certain traffic) |
{{cookiecutter.project_name}}/.github/ISSUE_TEMPLATE/bug_report.yml
Outdated
Show resolved
Hide resolved
…t.yml Co-authored-by: Isaac Virshup <[email protected]>
|
Ok, let's go with you suggestion, @ivirshup. We can always extend the template later if it turns out to be necessary. |
Close #57