Issue templates

[srittau]

I think that we should add a few issue templates to typeshed to guide contributors:

• Stub request – basically to steer contributors away from opening those. I.e. preferable stubs should be included in upstream package. Otherwise just open a PR to typeshed directly, open an issue only when discussion is required.
• Stub problem
• Other issue

(I have no immediate plan to work on this, this issue is mostly to write my thoughts down.)

[Akuli]

I do not want issue templates to typeshed.

One of my favorite things about typeshed is how little boilerplate our contributing process has. There is no CLA, no list of checkboxes when making pull request, and more generally, no issue or PR templates. Anyone can just make an issue or pull request without going through a "process". I believe this encourages more people to contribute.

Adding an issue template is IMO a step away from the "no process, just do it" spirit of typeshed, even if it doesn't have an annoying checklist.

[Avasam]

For PRs, GitHub already comes with links to Contributing Guidelines and Code of Conduct:

For issues, typeshed is different than most projects in that there isn't really runtime code that needs a specific setup or chain of events to replicate. Type false-positives/negatives are usually easy to reproduce, even with an incomplete reproducer. Off the top of my head, I can't remember any "sorry I'm not able to reproduce your issue" comment on issues.

So to @Akuli 's point, I don't think it needs much boilerplate in issues/PRs. Maybe some reminders hidden in markdown comments could be useful for something. Example of a comment:

<!-- Thank you for contributing to typeshed, make sure you're read <link to contributing guide> first. Please don't force push commits -->

The only thing that has caught my attention recently, is part of @srittau 's first point/example:

Stub request – [...] preferable stubs should be included in upstream package.

If that's something we want to encourage more, to at least know it makes sense for the stub to live in typeshed before committing to maintaining it. (the original library maintainer could be hesitant, not like static typing, not have enough experience to want to maintain, might want to use typeshed as a proof it works first, the project could've gone unmaintained, etc.)