[ProxCoques]

If Issues could be restricted to repo maintainers (with everyone else using Discussions), it would make contributing to F/LOSS projects far easier because you could easily see what the team was "thinking" (PR lists aren't like that).

As it is, most Issues are polluted by random support requests, suggestions and open-ended chat which obscures the focus so much that sometimes I just can't tell what they need help with, so I don't bother offering.

I have no interest in the Jirafication of Issue though. None at all.

[jeremy_k]

I agree. The issue with Issues and Discussions is no one knows where to put content. Most falls into Issues because Discussions aren't always enabled and Issues were the original dumping ground.

It would be nice to know that if you want to ask random questions or get guidance on how to use the project, go to Discussions. If you're looking for real bug reports, go to Issues. I'm not sure how to enforce Issues being only bug reports though. The first thing that comes to mind is having a triaging mechanism, but that puts more onus on maintainers to actually look through everything submitted and make a decision on it.

[lars_francke]

I'm sure you know but just to make sure. You can use Issue Templates to steer people towards Discussions. It's not perfect but it can help a bit at least.

https://docs.github.com/en/communities/using-templates-to-en...

[ProxCoques]

Yes, we've got that and it does help a bit. But we're often forced to be heavy-handed and just close junk issues with a comment asking the poster to open a Discussions thread. I feel bad about doing that though as it's hard not to come across as unfriendly.

[simonmic]

I do some things to try to separate and subtly prioritise bug reports and discourage excessively cluttering the tracker with ideas (some are useful to discuss there, but not all).

- Issue types, using labels: (Almost) every issue’s first label is A-BUG in weighty red or A-WISH in less substantial pink. The spellings keep these two first among labels and most visible. The word “wish” is carefully chosen. I attach one of these on first sight of a new issue.

- Shortcut urls that redirect to a view of one or the other of these, making it easy (for me at least) to focus: bugs.foo.org and wishes.foo.org showing just those, issues.foo.org showing both, prs.foo.org, regressions.foo.org, etc.

- New issue template that gives (short!) guidance and a hint that mail list and chat room are good for discussion and brainstorming. (GH Discussions would be pleasant now, but I’m not keen to fragment discussion more, or lock in even more on GH)..

[digging]

I feel this new version could help with that if unapproved users are restricted in the types of issues they're allowed to create. Something like "external". Or vice versa, they can't create "Internal" issues. But I immediately see a problem which is that types are not tags so the dichotomy of internal/external means that types now can't be used for type-of-work, only channel-of-input. So you'd be back to using tags for the former...

[okl]

> As it is, most Issues are polluted by random support requests, suggestions and open-ended chat which obscures the focus so much that sometimes I just can't tell what they need help with, so I don't bother offering.

Totally agree. They should have some AI solution categorize the issues and separate actual issues/tickets from support requests and other noise.

[ogoffart]

I've observed it has become much better on my repository over the past few years. Discussions took a while to be adopted and I have to guide users to discussions through the CONTRIBUTING.md and issue template. For the few questions that still comes in the issues, i'm immediately converting them into discussions.