DRAFT - Feature Requests in Discussions

[mamoodi]

End-user friendly description of the problem this fixes or functionality that this introduces

• Include this change in the Release Notes. If checked, you must provide an end-user friendly description for your change below

Introducing Discussions for Feature Requests

---

Give a summary of what the PR does, explaining any non-trivial design decisions

---

Link of any specific issues this addresses

---

To run this PR locally, use the following command:

docker run -it --rm   -p 3000:3000   -v /var/run/docker.sock:/var/run/docker.sock   --add-host host.docker.internal:host-gateway   -e SANDBOX_RUNTIME_CONTAINER_IMAGE=docker.all-hands.dev/all-hands-ai/runtime:90ff6e2-nikolaik   --name openhands-app-90ff6e2   docker.all-hands.dev/all-hands-ai/openhands:90ff6e2

[enyst]

I don't know about this, I don't think removing Feature Requests is a good idea? The PR is replacing feature requests with "small" things, which, sorry, I don't understand if or what it helps.

Sending the feature requests over to Discussions, where we already know very few people actually read, will likely only mean tremendously decrease their visibility, practically make them non-existent.

Can you please elaborate a bit on the reasoning for this proposal?

[mamoodi]

I don't know about this, I don't think removing Feature Requests is a good idea? The PR is replacing feature requests with "small" things, which, sorry, I don't understand if or what it helps.

Sending the feature requests over to Discussions, where we already know very few people actually read, will likely only mean tremendously decrease their visibility, practically make them non-existent.

Can you please elaborate a bit on the reasoning for this proposal?

Sure. I'll explain. Ultimately it is to involve the community in determining the features that would be valuable to them.

• The current Discussions has no visibility (currently closed) because it was never used for a particular purpose. If it gets repurposed for feature requests, it will serve a purpose and get more visibility. I will also forward community members there when they ask for a feature.
• The current Github Issues workflow doesn't really bring attention to features. Features get requested, they sit there, and if maintainers don't keep them alive, they go stale and close. And as the github issues are increasing (200 right now) the visibility gets even further reduced.
• Using the Github Discussions will allow a place concentrated for feature requests that community members can vote on and with specific rules to keep a healthy rotation.
• If this works, any user can also just go to Discussions to see what's in progress, on the roadmap and highly requested in one place.
• The "Small Enhancements" isn't great. Just couldn't find something that is not a bug but is not a feature. Definitely needs some polish.

I've been monitoring the Issues for a couple of months now and people adding feature ideas in there isn't giving them any feedback and almost no action. In this new way, the community can see whether their feature idea is shared with others and if so, progress of it being implemented rather than closed with no feedback.

All that being said, I'd love to know your opinions and be corrected if you believe the current feature requests in issues is working well.

[tobitege]

I'm a bit sceptical to switch from Issues to Discussions, since it is a major change, it needs loads more discussion about its consequences.
Relevancy, aim, usefullness, effort, planning, development resources - so many criteria for issues, that a move to discussions won't help, imho.
On the contrary, in every repo, Issues+PR is where I'd look, not discussions, because I see them for different audiences.
Do you have an example where this approach is currently "lived" by?

[enyst]

Ultimately it is to involve the community in determining the features that would be valuable to them.

• The current Discussions has no visibility (currently closed) because it was never used for a particular purpose. If it gets repurposed for feature requests, it will serve a purpose and get more visibility. I will also forward community members there when they ask for a feature.
• The current Github Issues workflow doesn't really bring attention to features. Features get requested, they sit there, and if maintainers don't keep them alive, they go stale and close. And as the github issues are increasing (200 right now) the visibility gets even further reduced.
• Using the Github Discussions will allow a place concentrated for feature requests that community members can vote on and with specific rules to keep a healthy rotation.
• If this works, any user can also just go to Discussions to see what's in progress, on the roadmap and highly requested in one place.
• The "Small Enhancements" isn't great. Just couldn't find something that is not a bug but is not a feature. Definitely needs some polish.

I've been monitoring the Issues for a couple of months now and people adding feature ideas in there isn't giving them any feedback and almost no action. In this new way, the community can see whether their feature idea is shared with others and if so, progress of it being implemented rather than closed with no feedback.

Some very good points here! Thank you for your patience, Mamoodi, and for thinking this over.

Well. I frankly don't know of a great way to track feature requests. It's like, you can use many many things in a small team and they will likely work, while in public or at large... is another story. I'm with you that GitHub's issues are far from ideal, it's just, so are others.

I hear you on the little community involvement here in features. I'm afraid we're against a very normal thing: the vast majority of people who ever come around an open source project will not interact with it, if they do it's for a particular pet peeve, most read and don't post, or post once and move on. That's just how things work.

That's even more reason why I'm actually impressed by your argument. ❤️ My assessment might not be the same as yours, on the likelihood that this change would increase community involvement. But I really appreciate you thinking things over and trying to improve what is, IMHO, very hard; permanently a challenge.

Can Discussions be linked / tracked on the Project Roadmap like GitHub issues can?

[mamoodi]

I'm a bit sceptical to switch from Issues to Discussions, since it is a major change, it needs loads more discussion about its consequences. Relevancy, aim, usefullness, effort, planning, development resources - so many criteria for issues, that a move to discussions won't help, imho. On the contrary, in every repo, Issues+PR is where I'd look, not discussions, because I see them for different audiences. Do you have an example where this approach is currently "lived" by?

Yeah that's fair. As you mentioned there's a lot that needs to be considered to take on features. Just trying to come up with a way to get more input from community naturally without sending surveys and such. I'm worried that with the amount of issues that are in the repo, it will eventually just be a place with 1k+ issues and no visibility into what's being worked on.

I know that's pretty usual for popular open source projects but then makes me wonder what the value of opening up issues becomes.

Xingyao originally mentioned this repo: https://github.com/warpdotdev/Warp/discussions
I think they choose the features from the github issues and bring them over to Discussions to be voted on. We can definitely do that.
They have 2300 issues which I can't fathom how that works 🙈

My mind doesn't comprehend beyond 30 issues but I may be an outlier there :D

[tobitege]

That's what I was thinking about it: it'd be shuffling the issues with issues around, but the problems that @enyst mentioned stay the same.
The automatic closure of untouched issues will keep a lid on the "open" number to some extend.
But I wouldn't expect for anyone to try to keep track of all of them on their own. If anyone wants to contribute, they should be smart enough to use search and filtering, to find something worthwhile to implement. 😄

[mamoodi]

Some very good points here! Thank you for your patience, Mamoodi, and for thinking this over.

Well. I frankly don't know of a great way to track feature requests. It's like, you can use many many things in a small team and they will likely work, while in public or at large... is another story. I'm with you that GitHub's issues are far from ideal, it's just, so are others.

I hear you on the little community involvement here in features. I'm afraid we're against a very normal thing: the vast majority of people who ever come around an open source project will not interact with it, if they do it's for a particular pet peeve, most read and don't post, or post once and move on. That's just how things work.

That's even more reason why I'm actually impressed by your argument. ❤️ My assessment might not be the same as yours, on the likelihood that this change would increase community involvement. But I really appreciate you thinking things over and trying to improve what is, IMHO, very hard; permanently a challenge.

Can Discussions be linked / tracked on the Project Roadmap like GitHub issues can?

Doesn't seem like you can link them: https://github.com/orgs/community/discussions/11223

The funny part is while searching for that I ran into this: grafana/grafana#73424

Your points are really valid. You have more experience in OSS than me so it may just be something that we have to live with. Spending time on the github issues, I do really wonder what the value is of having 3933 open issues. Even at 200 issues the search doesn't even really help when I KNOW something exists and want to find it.

So I guess the question is, do we think there is a way to better involve the community on the feature request workflow? Or it's business as usual. Open an issue, gets stale, move on.

I may be wrong but since June 2024, I don't think I've seen a feature request be opened by one person, and then worked on by another person that didn't already have that feature request in their sights.

What do you all think? Am I trying to fight an already lost battle?

[tobitege]

Maybe openhands can be used to help in identifying duplicates, apply tags for error, QoL, 3rd party tool integration etc.?
I haven't thought about in which form the results could be made useful here, though.

[mamoodi]

Maybe openhands can be used to help in identifying duplicates, apply tags for error, QoL, 3rd party tool integration etc.? I haven't thought about in which form the results could be made useful here, though.

It's more so about identifying features that would bring the highest values to the users and allowing the community to take part in that process, rather than the issue management like tagging/duplicates/etc.

[mamoodi]

I'm going to rethink this over the holidays. Thanks for your input 🙏