New repo unit: Discussions (ALT: type selector for issues) #169

jwildeboer commented 2024年05月22日 20:30:17 +02:00

I am posting this here to make a point ;)

The issue tracker in Forgejo is a very powerful feature, especially in combination with projects. However - categorising content is not (yet) possible, only with some hacks.

In many projects, I see the need for a clear separation of code-related issues and more generic discussions that the issue tracker doesn't really reflect.

That is the reason this repo even exists, IMHO ;)

So before I post [FEAT] feature request in forgejo's issue tracker, let me describe two possible solutions here.

Solution #1 A new unit

Create a new unit per repo called "Discussion" which is effectively an issue tracker but without the code features. So almost all code can be reused, it's "just" another unit to activate like Wiki etc.

Solution #2 A new (definable) list of issue categories

Issue (templates) should have a checkbox element that allow to classify the issue.

• Code Issue
• Discussion
• Feature

And maybe more. These classifiers should be editable. So code issues (aka bugs) could become Discussion when they move beyond pure code and are indicative of a more general (architectural) discussion.

Feature requests could move to code issue once a PR is available.

Fundamental thoughts

Mixing bugs and discussions can be helpful, but depending on the project, it can also be distracting for coders and architects. Allowing coders to filter issues based on classification helps them focus on code issues while the general audience can engage in more general discussions.

I am not sure which solution is the best approach. But both proposed solutions can be easily combined, IMHO. This would be a helpful solution to make projects more attractive to coders and user.

Please discuss.

I am posting this here to make a point ;) The issue tracker in Forgejo is a very powerful feature, especially in combination with projects. However - categorising content is not (yet) possible, only with some hacks. In many projects, I see the need for a clear separation of code-related issues and more generic discussions that the issue tracker doesn't really reflect. That is the reason this repo even exists, IMHO ;) So before I post [FEAT] feature request in forgejo's issue tracker, let me describe two possible solutions here. ## Solution #1 A new unit Create a new unit per repo called "Discussion" which is effectively an issue tracker but without the code features. So almost all code can be reused, it's "just" another unit to activate like Wiki etc. ## Solution #2 A new (definable) list of issue categories Issue (templates) should have a checkbox element that allow to classify the issue. - Code Issue - Discussion - Feature And maybe more. These classifiers should be editable. So code issues (aka bugs) could become Discussion when they move beyond pure code and are indicative of a more general (architectural) discussion. Feature requests could move to code issue once a PR is available. ## Fundamental thoughts Mixing bugs and discussions can be helpful, but depending on the project, it can also be distracting for coders and architects. Allowing coders to filter issues based on classification helps them focus on code issues while the general audience can engage in more general discussions. I am not sure which solution is the best approach. But both proposed solutions can be easily combined, IMHO. This would be a helpful solution to make projects more attractive to coders and user. Please discuss.

Ghost commented 2024年05月22日 20:56:00 +02:00

So before I post [FEAT] feature request in forgejo's issue tracker

It's already there: forgejo/forgejo#410
Semi related: Threaded comments on issues

> So before I post [FEAT] feature request in forgejo's issue tracker It's already there: https://codeberg.org/forgejo/forgejo/issues/410 Semi related: [Threaded comments on issues](https://codeberg.org/forgejo/forgejo/issues/2177)

efertone commented 2024年05月22日 21:11:58 +02:00

To me it feels like a classic use-case for labels, like Kind/Discussion, the issue page can exclude labels, they can be easily converted into an actionable item, they can be added to specific Projects for scoped list. A huge improvement I see would be if we can easily filter out labels in the search bar with wildcards like -label:Discussion/* and that would exclude all Discussion/something labels.

For the first unit, I hope one day Forgejo can have a discussion page, but that shouldn't work like an issue. Like on GitHub, a discussion page should have threads. The main reason I don't like longer discussions on issues and pull request, and the reason I comment on a random line with extra thought, because that's where people can answer to that topic and no one has to parse threads from a single list of comments. Having a Discussion would be very confusing to people coming from GitHub, where it's a thing, and it would limit how it can be implemented later.

Adding an extra category property, with customisable values, that's what labels are.

To me it feels like a classic use-case for labels, like `Kind/Discussion`, the issue page can exclude labels, they can be easily converted into an actionable item, they can be added to specific Projects for scoped list. A huge improvement I see would be if we can easily filter out labels in the search bar with wildcards like `-label:Discussion/*` and that would exclude all `Discussion/something` labels. For the first unit, I hope one day Forgejo can have a discussion page, but that shouldn't work like an issue. Like on GitHub, a discussion page should have threads. The main reason I don't like longer discussions on issues and pull request, and the reason I comment on a random line with extra thought, because that's where people can answer to that topic and no one has to parse threads from a single list of comments. Having a Discussion would be very confusing to people coming from GitHub, where it's a thing, and it would limit how it can be implemented later. Adding an extra category property, with customisable values, that's what labels are.

fnetX commented 2024年05月22日 22:57:54 +02:00

I second your option about configurable issue trackers. I proposed the same in a similar Gitea issue here: https://github.com/go-gitea/gitea/issues/17858#issuecomment-981977326

There are thousands of possible use cases. Separating Feature Requests from Bugs, Confirmed ToDos from New Reports, User Support from Discussion, Have separate tracker for frontend and backend team and much more.

However, I think the tabbed UI is not a good solution. I asked for input about GH discussions here forgejo/forgejo#410 (comment). From my experience, people often mis-post issues in GitHub and they are then "turned" into discussions and vice versa. And the display of the threads might be confusing.

From a UX perspective, I'd recommend looking into the following:

• instead of only allowing types of issues per the New Issue form, allow people to prominently select what they want
• sort issues by labels only (e.g. type/discussion, type/support, type/x...)
• allow to configure a default display (e.g. to only show bugs and feature requests by default)
• allow to configure "prominent" filters, e.g. "Confirmed Bugs with high priority" per repository
• and otherwise make it convenient to switch between the types of "Issue"
  -. rename issues to something else

It will need a lot of work, though. The upside is: It can be done in small steps and would improve issue management in general, not only discussions.

The downside of the Github-ish way of having a second tab is that people might get confused where to search for, and as soon as you want to start to separate into three things (e.g. ToDos for developers, Feature Request discussion and User Support), things are basically impossible to track via the tab bar.

I second your option about configurable issue trackers. I proposed the same in a similar Gitea issue here: https://github.com/go-gitea/gitea/issues/17858#issuecomment-981977326 There are thousands of possible use cases. Separating Feature Requests from Bugs, Confirmed ToDos from New Reports, User Support from Discussion, Have separate tracker for frontend and backend team and much more. However, I think the tabbed UI is not a good solution. I asked for input about GH discussions here https://codeberg.org/forgejo/forgejo/issues/410#issuecomment-1786886. From my experience, people often mis-post issues in GitHub and they are then "turned" into discussions and vice versa. And the display of the threads might be confusing. From a UX perspective, I'd recommend looking into the following: - instead of only allowing types of issues per the New Issue form, allow people to prominently select what they want - sort issues by labels only (e.g. type/discussion, type/support, type/x...) - allow to configure a default display (e.g. to only show bugs and feature requests by default) - allow to configure "prominent" filters, e.g. "Confirmed Bugs with high priority" per repository - and otherwise make it convenient to switch between the types of "Issue" -. rename issues to something else It will need a lot of work, though. The upside is: It can be done in small steps and would improve issue management in general, not only discussions. The downside of the Github-ish way of having a second tab is that people might get confused where to search for, and as soon as you want to start to separate into three things (e.g. ToDos for developers, Feature Request discussion and User Support), things are basically impossible to track via the tab bar.

PowerUser commented 2025年11月11日 21:44:55 +01:00

I've noticed some repositories on GitHub have started using discussions lately, and I've noticed it generally improves the quality of their issue tracker.

Generally what I've seen projects do is this:

• block users from creating issues
• redirect them to opening discussions
• convert discussions to issues as needed

This has a number of benefits:

• Developers get to decide whether an issue is actually an issue, before it gets put on the project's to-do list.
• Users get a valid place to ask questions and discuss non-issue topics. (Asking for help, sharing cool screenshots, tutorials, etc.)
  • This conversation can lead to the discovery of more valid bugs that wouldn't otherwise get reported.
• The discussions tab (on github) doesn't have a number on it, so having a ton of open discussions isn't a bad look, unlike issues.

I'm not saying that forgejo should implement exactly what GitHub has, but I do think that discussions is a positive force on their platform, and it would be worth taking notes.

If you want to see an example of this practice, I recommend checking out the issue tracker and issue-creation flow over at github:ghostty-org/ghostty.

I've noticed some repositories on GitHub have started using discussions lately, and I've noticed it generally improves the quality of their issue tracker. Generally what I've seen projects do is this: - block users from creating issues - redirect them to opening discussions - convert discussions to issues as needed This has a number of benefits: - Developers get to decide whether an issue is actually an issue, before it gets put on the project's to-do list. - Users get a valid place to ask questions and discuss non-issue topics. (Asking for help, sharing cool screenshots, tutorials, etc.) - This conversation can lead to the discovery of more valid bugs that wouldn't otherwise get reported. - The discussions tab (on github) doesn't have a number on it, so having a ton of open discussions isn't a bad look, unlike issues. I'm not saying that forgejo should implement exactly what GitHub has, but I do think that discussions is a positive force on their platform, and it would be worth taking notes. If you want to see an example of this practice, I recommend checking out the issue tracker and issue-creation flow over at [github:ghostty-org/ghostty](https://github.com/ghostty-org/ghostty).