[octref]

Well, here are two things that have been brought up many times:

1. Required fields on new issues. Has been requested since 2016[0].

2. Better issue search.

Open Source projects face a lot of issues. It's good to talk about them, but some GitHub can solve some GitHub can't. I'd be much happier to see these problem addressed instead of learning about updating my profile status[1].

Currently when a project becomes popular the issues easily drown the author. As the communication portal between OSS authors and users, GitHub can and should give OSS authors more power.

[0]: https://github.com/dear-github/dear-github

[1]: https://github.blog/changelog/2019-01-09-set-your-status/

[Karunamon]

Regarding 1: Please no. Prefilling the entry box is a decent compromise and doesn't require turning the Github issue screen into a Jira issue screen.

[jnbiche]

If someone is filing an issue to an open source project -- whose maintainer will very often be working on said issue for free -- the least that person can do is submit the issue with the information that the maintainer requests.

I really like this idea if for no other reason that it would raise the bar for submitting an issue. So many open source maintainers on Github are overwhelmed with vague issues or support requests masquerading as issues.

[dspillett]

> 1. Required fields on new issues.

That is unlikely to improve matters IMO. If people are forced to populate a box they were otherwise going to ignore they'll populate it with repeated detail from elsewhere, a single character if no minimums are imposed, or keyboard mashing gibberish, not the sort of detail you are asking for.

Many people are just incapable of, or unwilling to spend the time to, produce useful bug reports and feature requests. They expect you to be clairvoyant, or be willing to go back and forth re-asking the same questions until you have the information you need.

In DayJob we have commercial clients who are supposed to perform their own first-line support and triage issues before sending them to us (their procurement people expect a per-user price reduction because they claim to do this), yet we still always have a collection of issues on-hold awaiting information because the report essentially said nothing more detailed than "a user says that they did something and there was an error message" with the required detail fields containing something along the lines of "see title". Bad reports end up costing them in various ways and they still can't be bothered to raise them correctly. (Heck, sometimes internal work items & bug reports raised by other devs/BAs/management can be just as bad but at least I'm allowed to be sarcastic in response to those!) I wouldn't expect the general public filing a reports/requests in a project on GitHub to average any better.