Lumping all FRs into one topic on the forum makes it incredibly difficult (read: impossible) for devs to track FRs.
With GitHub issue labels there is no reason that I can see that should stop feature requests from being moved to their respective repositories. This will make it easier to differentiate between frontend requests, core requests, app requests, etc.
In addition, to mitigate convolution specifically for core FRs, there should be a specific label for “New Integration” requests. The core development team has little or nothing to do with new integrations most of the time, so there should be a differentiation between a core FR and a new integration request.
This change would bring an overall improvement to the interaction between the community and developers, and should prove beneficial to both parties. People making the requests will actually be heard, and people implementing the requests will be able to actually track progress.
Not true. This reply is a proof of that.
I like browsing this part of the forum and implement some stuff from time to time.
Recent implementation from my end, inspired by FRs here: not conditions and segment support for WLED.
It seems silly to me, but to be fair I am not a core dev. If the main team is happy with things the way they are then I accept that I just personally think tracking through GitHub is more efficient.
Hopefully the links to GitHub FR for the non-core repos will help the other devs.
The core repo currently has 1,106 open issues (and that’s with us attempting to limit it to bug reports). If we accepted feature requests there, we’d easily double that number – over time, we’d start having: more and more issues being closed automatically because of staleness (which would put stress on the both the developers and the community).
Speaking just for myself, I would need to see a much larger community effort to help us reduce that bug count before I would feel comfortable accepting feature requests there.
That is correct, but also a pain point. Bram and I have been discussing on how to standardize it across all repositories.
This is one of the main reasons. It is already hard to keep track due to the volume and the reason why feature requests for the core are in here.
One of the options that is being considered right now, is using a (to be rolled out, not yet available) new GitHub feature. However, GitHub is not as accessible for everybody compared to the forums.
How about formalising the forum ‘Feature Requests’? For example if a sufficient number of votes are registered a Dev will respond with some kind of high level appraisal?
Like in the UK anyone can start an on-line government petition and if enough people sign then it is discussed by Parliament. ‘Discussed’ being the operative word here. It certainly doesn’t mean any decision, promise or change is made.
In our case here it would at least give some kind of reassurance that the popular requests have been noticed.
But as I said, I’m talking out of the top of my head and there could be many reasons this isn’t a workable idea.
This is not how open source development works. It is not like I’m going to implement the feature request for some kind of integration for a device I do not own.
For a really long time I never knew I needed to vote for my own FR’s. I assumed since I wrote it that would imply that I had “voted” for it (why would I not?). Until someone pointed out once that I hadn’t voted my own FR.
)
I just personally think tracking through GitHub is more efficient.