Update issue template to include a checklist

[max-sixty]

This may be overly prescriptive. We've had a number of recent issues which aren't minimal and link to external data, and then these languish on the Issue Tracker unanswered. That's a loss of time for all involved — the reporter of the issue as well as the maintainers.

To the extent we can predict which issues will languish, it would be better to give that guidance up front, and encourage examples which are easier to engage with. So this introduces a checklist that people need to proactively fill out.

[github-actions]

Unit Test Results

         6 files           6 suites   58m 39s ⏱️
16 227 tests 14 492 ✔️ 1 735 💤 0 ❌
90 558 runs  82 381 ✔️ 8 177 💤 0 ❌

Results for commit 586498a.

♻️ This comment has been updated with latest results.

[TomNicholas]

I think this is necessary too - only thing I would add is something along the lines of "this will help you get your question answered faster!"

[mathause]

Was this superseeded by #6119?

[max-sixty]

Not quite; since this given a specific checklist that people need to complete. Sorry I let this linger. I can finish soon-ish.

[max-sixty]

@pydata/xarray

I've refreshed this, since I've been spending time in the issue tracker recently and would like to systematize myself out of the "please add an MVCE" triagooor.

I also added a empty binder notebook & link, so people can easily test against a current version of dependencies. I've been using this myself given my M1 has been prickly for some xarray dependencies. Binder is great.

I'd be up for making it more friendly, if possible. But I do think we should be strict on issue quality. Some claims:

• Most people want to¹ invest the time to make good issues, and the existing outcomes are mostly a gap of direction & nudging
• An unanswered issue (of which we have many, unfortunately) is worse than no issue at all — people feel that there's no prospect of a resolution to their concerns
• Bad issues take time away from good issues, and lower maintainers' willingness to spend time in the issue tracker
• Friendliness is a virtue. It's difficult to be friendly when managing bad issues, it's very easy when dealing with good issues

This is the current draft:

And the checkboxes:

Footnotes

1. or at least are not adverse to :) ↩

[mathause]

Your suggestion looks good - did you close this on purpose?

[max-sixty]

Sorry, thanks for letting me know, that was a mistake. I'll restore.

I've had some issues with my github scripts today...