Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add participant to an issue #22470

Open
xluk9 opened this issue Jan 16, 2023 · 3 comments
Open

Add participant to an issue #22470

xluk9 opened this issue Jan 16, 2023 · 3 comments
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.

Comments

@xluk9
Copy link

xluk9 commented Jan 16, 2023 •
edited
Loading

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
@xluk9 xluk9 added type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first. labels Jan 16, 2023
@dovydasz
Copy link

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

@xluk9
Copy link
Author

xluk9 commented 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.

@abes-vohu
Copy link

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 up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
type/feature Completely new functionality. Can only be merged if feature freeze is not active. type/proposal The new feature has not been accepted yet but needs to be discussed first.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dovydasz @xluk9 @abes-vohu