Better issue template?

[dukecat0]

Currently, we have only one issue template for users to report issues that they are experiencing. Maybe we should add issue templates for feature requests and questions?

Also, maybe we could use issue forms instead of Markdown templates?

[bhrutledge]

I don't feel strongly about this. While I like GitHub's improved support for issue templates and forms, and I haven't found the volume/quality of Twine issues to be a problem. But, it might be worth revisiting the current template, and seeing what's still relevant and/or missing. Also, it does seem like pip's bug report form is friendlier than the Markdown template.

I'd like to hear from @sigmavirus24 before investing time in this.

[sigmavirus24]

There's genuinely little to add in the way of features and I'd rather issues not be used for general support questions as there are far more appropriate places for that. Requests tries to use this to redirect people but they just ignore it and file the issue anyway. I'm all for improving the bug report template if there's something there to improve

[bhrutledge]

I'd rather issues not be used for general support questions as there are far more appropriate places for that.

@sigmavirus24 Where do you recommend folks go for general support questions?

It seems like a common type of Twine issue is something that looks like a bug to the user, but turns out to be a support question due to their configuration.

[sigmavirus24]

I'm all for people opening issues for things that seem like bugs which end up having been support requests due to helping them debug things. Better would be a list of common debugging steps that people provide the answer to that can help prevent an issue. I don't want "How do I do ... ?" questions when there's at best one of us that has the time to handle those. We don't have a strong community of folks here helping triage issues because there isn't a large volume. There are places like StackOverflow and discuss.python.org that have large communities that can help answer those questions.

[dukecat0]

Better would be a list of common debugging steps that people provide the answer to that can help prevent an issue.

Maybe we should put these debugging steps in the docs? And suggest folks checking it before filing issues.

However, if they just ignore it and filing issues directly... (Currently, the solution I have is giving a checkbox about reading debugging steps in issue template.)

[dukecat0]

Also, it does seem like pip's bug report form is friendlier than the Markdown template.

Yes, and issue forms can mark some fields with an asterisk (*) and folks are required to fill in them. Otherwise, they won't be able to submit the issue.

[sigmavirus24]

Maybe we should put these debugging steps in the docs? And suggest folks checking it before filing issues.

That doesn't work in practice.

Yes, and issue forms can mark some fields with an asterisk (*) and folks are required to fill in them. Otherwise, they won't be able to submit the issue.

Sometimes we add things to Twine to help with debugging that will never be available on older versions. If we start requiring that information, we exclude a whole class of users who can't upgrade their own software. I don't know that there are genuinely any questions we can forcibly require in this manner. Also just because we require them doesn't mean users will give accurate or useful information if they can't discern how to find it or provide it.

It seems like folks have taken an "Assume worst intent" approach to making issue templates of late. Making it more difficult to report a bug is not what I think we should be doing. We should be doing more to make filing bugs unnecessary.

[dukecat0]

Making it more difficult to report a bug is not what I think we should be doing. We should be doing more to make filing bugs unnecessary.

I agree with you.

So probably this issue is just for using issue forms instead of Markdown template? Other things should remain unchanged?

[dukecat0]

And also, could we have OS-specific troubleshooting tips in the docs? Then we can lead folks to try them out before filing an issue. I noticed this in #11 and it hasn't been added to the docs yet.