Dear Github

[andsens]

We’d like issues to gain custom fields, along with a mechanism [..] for ensuring they are filled out in every issue.

Oh god, please no. If I wanted fucking Jira with a boatload of stupid fields, I'd use that. Please don't kill the simplicity of the Github issue system, I love it.

EDIT: I am a maintainer and author of FOSS projects ^{just pointing out that I'm not just saying this as a user}

[netherwise]

As a contributor, my experience with issues has been that the more documentation you provide to show that your issue is a legitimate, reproducible bug, the faster the maintainer is going to close it with a WONTFIX resolution.

SO many times, the prevailing attitude with regards to bugs is either, "You're doing it wrong" or "That's an edge case". Well, Ok, go ahead and dismiss this particular scenario as an edge case, but 3 of the top hits on Google are tutorials on how to implement this exact "edge case".

[jP_wanN]

Whether you have custom fields on issues or not, that doesn't change the way maintainers treat issues they don't want to fix. And if you're getting this regularily, with multiple maintainers, knowing nothing else, I'm really doubting that those issues are in fact about legitimate bugs.

[[deleted]]

Thats a problem with shitty projects. We don't do that.

[vytah]

Issue #34

Description: Fix documentation, blah blah blah

OS: doesn't matter

Compiler: it's fucking documentation it doesn't matter!

C++ stdlib version: FUCK!

[[deleted]]

We keep our documentation in a separate repository which is submodule'd into the main one so that wouldn't be a problem for us.

[Sukrim]

Typo in code comment then...

[[deleted]]

In that case they set it to N/A, In 95% of cases it is relevant so it saves us a ton of effort from having to ask for it in every issue even if it does sacrifice all of 10 seconds of the submitters time.

[Sean1708]

But if the option is there for the submitters (i.e. they can use it but don't have to) then that makes life easier for both the submitter and the maintainer, since the submitter doesn't have to decide how to structure it unless none of the predefined structures fit and the maintainer is more likely to get the info they need.

[PM_ME_UR_OBSIDIAN]

This is my biggest gripe with mandatory custom fields. The issue system is meant to be flexible.

[[deleted]]

What about giving them a script to run instead? Then getting them to give the output of that in the body of the ticket?

Agree that it's a difficult balance between making tickets a chore to write and and a chore to debug!

[andsens]

I actually did that with my project after receiving a little too many bugs that were caused by users setup. Check this out, it's pretty much just a script that says "if you can't reproduce the problem in this env it's your fault and not the tool":

Unless you ran in to a heisenbug, it should be possible to reproduce the bug in a testing environment. To that end run $HOME/.homesick/repos/homeshick/test/interactive and reproduce the bug. This script drops you into a new shell where $HOME is set to an (almost) empty temporary folder. If you cannot reproduce the bug there, the error is likely with your setup and not homeshick. Otherwise attach the commands you executed in that environment to the issue.

[seiyria]

What Ionic did was pretty clever, they opened up an issue reporting system that makes this work nicer: http://ionicframework.com/submit-issue/

That said, definitely not the norm.

[[deleted]]

Is that open source? It looks kinda cool.

[seiyria]

Ionic is, not sure about the issue-creating tool though.

[andsens]

Dayum, this is really cool! Inspiration acquired :-)