Add participant to an issue #10109

New Issue

GiteaMirror · 2025-11-02T08:58:24-06:00

GiteaMirror commented

2025-11-02 08:58:24 -06:00

Originally created by @xluk9 on GitHub (Jan 16, 2023).

Feature Description

I think it would be great to have the possibility to manually add a participant to an issue, so that I can involve non-developer people in the discussion of an issue. The need arise because some people in my company should participate in issues, but they refuse to "watch/susbscribe" to a repo/issue. It becomes a liability issue. I know it is my company fault, I know it very well. But I think is a reasonable solution for these type of people.

When a person is added as participant to an issue, they should be automatically subscribed to the notifications of the said issue. They should have the liberty to unsubscribe to the notifications, but they should remain as participant. In this way, there is a soft enforcement on "this is issue involves you and you are a participant of it, so you should have followed it and given your opinion/feedback".

It might be in conflict with assignee. Correct me if I'm wrong, but I view assignee as more developement-oriented, in the sense that they are the one responsible for the fix/implementation of an issue. Maybe there is another way to solve this problem.

Screenshots

No response

Originally created by @xluk9 on GitHub (Jan 16, 2023). ### Feature Description I think it would be great to have the possibility to manually add a participant to an issue, so that I can involve non-developer people in the discussion of an issue. The need arise because some people in my company should participate in issues, but they refuse to "watch/susbscribe" to a repo/issue. It becomes a liability issue. I know it is my company fault, I know it very well. But I think is a reasonable solution for these type of people. When a person is added as participant to an issue, they should be automatically subscribed to the notifications of the said issue. They should have the liberty to unsubscribe to the notifications, but they should remain as participant. In this way, there is a soft enforcement on "this is issue involves you and you are a participant of it, so you should have followed it and given your opinion/feedback". It might be in conflict with assignee. Correct me if I'm wrong, but I view assignee as more developement-oriented, in the sense that they are the one responsible for the fix/implementation of an issue. Maybe there is another way to solve this problem. ### Screenshots _No response_

GiteaMirror added the type/proposal type/feature labels 2025-11-02 08:58:24 -06:00

GiteaMirror commented

2025-11-02 08:58:25 -06:00

@dovydasz commented on GitHub (Jan 18, 2023):

I mention a person in the text, for example, ping @John so he receives a message. works well for us :)

@dovydasz commented on GitHub (Jan 18, 2023): I mention a person in the text, for example, ping @John so he receives a message. works well for us :)

GiteaMirror commented

2025-11-02 08:58:25 -06:00

@xluk9 commented on GitHub (Jan 25, 2023):

I mention a person in the text, for example, ping @john so he receives a message. works well for us :)

Yeah, it came to my mind after I created the post. Even tough I don't find id particularly elegant to do this way, for now this seems the only solution.

It will take time, I still need to get around the code base. I'm more than willing to, given I find the time, to make a pull request with this feature.

@xluk9 commented on GitHub (Jan 25, 2023): > > I mention a person in the text, for example, ping @john so he receives a message. works well for us :) Yeah, it came to my mind after I created the post. Even tough I don't find id particularly elegant to do this way, for now this seems the only solution. It will take time, I still need to get around the code base. I'm more than willing to, given I find the time, to make a pull request with this feature.

GiteaMirror commented

2025-11-02 08:58:25 -06:00

@abes-vohu commented on GitHub (Nov 21, 2024):

I think this is a good idea. In our case, it often happens that issues are unfortunately only reported verbally or by phone to the development team, and using @reportingUser is not very effective. I would prefer that the user be included in the "Participants" list with all rights and responsibilities.

Especially when it comes to beta testing, the reporter needs to be involved in deciding whether the issue (whether it's a bug or a feature) has been resolved to their satisfaction.

This approach would help ensure better tracking and accountability for reported issues, as well as improve communication between reporters and developers throughout the resolution process.

@abes-vohu commented on GitHub (Nov 21, 2024): I think this is a good idea. In our case, it often happens that issues are unfortunately only reported verbally or by phone to the development team, and using @reportingUser is not very effective. I would prefer that the user be included in the "Participants" list with all rights and responsibilities. Especially when it comes to beta testing, the reporter needs to be involved in deciding whether the issue (whether it's a bug or a feature) has been resolved to their satisfaction. This approach would help ensure better tracking and accountability for reported issues, as well as improve communication between reporters and developers throughout the resolution process.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#10109