feature requests to be better managed

[Elypha]

Hi there

I'm not so certain of how you handle feature requests but from what I see under https://github.com/immich-app/immich/discussions/categories/feature-request, it looks quite messy with many topics opened months ago but no discussion at all. I'm not sure how much importance the dev team places on this, but as a developer myself, I feel like I have absolutely no desire to work on it when faced with 100+ of these requests in 8 pages.

What I think might be better is to get requests sorted, for example, features the dev team prioritise and features frequently requested by the community. Probably it would also be better to archive and close those requests that have been open for years but receive no upvotes and discussion. From what I see there are duplicated requests to merge, for example, #1690 and #2376, and dead requests probably to close like #1650 - neither clear information was provided and the author has also disappeared.

This is just my personal opinion and I would love to know what the developers think.

[Elypha]

btw I think it doesn't matter but if you are interested, the story is that I visited back to check out this project and found that the demo still doesn't support 'scroll to zoom'. I remember I had the same idea probably a year ago and I found some very positive discussions on implementing it. I'm just a bit surprised that no one has felt the need and contributed code since that.

[Elypha]

Thanks for your reply and I got your point. I'm not urging the zoom feature but I appreciate your kind explaination. One more thing I'd like to comment is that not only devs but also users who come to this repo to see the feature requests for their own problems. I assume many won't read through page 1 to 8 and the search isn't always promising either, which is to say the vote sorting is probably only valid for the first page. I didn't do a research on this but I think you get my idea. They will vote better if they have a cleaner overview of the on-going discussions.
Anyway I hope I don't sound like I'm trying to teach anyone to do that. I'm just talking my personal experiences since immich is the most promising one for my need out of all the others.

[alextran1502]

No problem at all here. We agree that using discussion for feature requests is not the most intuitive way to manage features, but it helps with not flooding the actual issue list. Do you have any suggestions on how to manage feature requests better?

[jrasm91]

I think, some of the suggestions by OP include (1) stay on top of closing duplicates, and (2) removing old/outdated feature requests. Related, I'm sure we could in general "clean up" the list, so that it was a bit clearer the status of things. For example, there are lots of requests for album sorting. We could make a single team-approved feature request that has a more clear explanation on our thoughts/goal for the topic and spur discussion on it.

[Elypha]

From what I see the common practice without 3rd party service is to use a labelled issue list and a pinned road map thread to update and show selections that users can read before they do anything. The combination will also work based on discussion I think, so that we can have an issue list for actual issues. But yes, it requires some extra effort for maintenance so it depends on how much you think this will benefit user discussions.
Or maybe in the simplest case, a three-tier label system can be adopted, for example, (a) features that already have people willing to help, i.e., high priority; (b) features that are possible soemtime in the future but not now - low priority; (c) features that are too vague/outdated to work on - information needed, etc. The intention is that, in this way, users can better understand what the current development team is focused on and what the main points of the project are - rather than making super broad requests (if you ask 10 people, you might get 30 desired features, which leads this project to be a universal solution for all cases, and I guess that's not what you are aiming at xd

[jrasm91]

Yeah, I think we basically categorize the features requests like that when we read them, we just don't always add labels or comments to communicate that back, so that is something we could experiment with doing.