As the v4 is becoming more widely used, it is becoming increasingly difficult to keep track of the features requested by the community, and above all, it has become urgent to have a way to prioritize developments.
We use GitHub for development to list planned/ongoing/completed developments.
However, I am receiving more and more development requests, and currently, my only way of knowing that « this development is in high demand » is to remember that I have seen this request in several posts: in short, itâs not sustainable
I have therefore created the Feature requests category on the forum.
This category is very simple: itâs a board where each post is a feature request. Then, everyone on this forum can vote for the features they would like to see in Gladys.
This list, ordered by number of votes, will give anyone who wants to help us with Gladys an idea of the most requested features.
This category does not replace GitHub
Be careful, this category is not meant to replace our current GitHub workflow, which remains the same.
Did you find a bug in Gladys? Create a GitHub issue.
Do you have a Philips Hue bulb not supported by Gladys? Create a GitHub issue.
Are you developing on Gladys and want to reference your development? Create a GitHub issue.
This category is useful upstream of GitHub. It is intended for « users » who want to make their voices heard and see if other users want the same feature in Gladys
The new workflow
The user creates a feature request on the forum
The feature receives a large number of votes
After discussion with the Gladys maintainers, we decide that the feature will be developed
A GitHub issue is created
We add a reference to the GitHub issue on the forum in the feature post
The feature is developed, we close the GitHub issue and the forum topic, with a post explaining the development carried out.
Indeed, we can add some already planned items to set an example and link the forum post to the issue/PR This will help better connect GitHub, which is only read by developers, with the community, which is only read by users.
@AlexTrovato You are a « Trust level 2 » member, so you have 6 votes to distribute, right?
I donât find it crazy, otherwise everyone will vote for everything and there wonât really be a difference between the features.
We can re-evaluate the number of votes available per user when there are more posts. For example, if there are 100 features in the category, we can give 15 votes so that the user can vote for the 15% they prefer. What do you think?
Itâs not possible to disable the best answer feature for a category only, at least I havenât found it!
I also agree. 15% really allows you to focus on the main features you are looking for. And as progress is made, you can choose other options.
By the way, when you create a topic, does it count as a vote for the creator or do we also have to vote on it? If not, maybe specify that because Iâve seen topics created without votes, and Iâve done the same ^^
Normally, yes! When a feature is developed and the topic is closed, the votes are released, isnât that the case?
If everyone votes for everything, we will have perfect equality between all features, which defeats the purpose of having a voting system.
If youâve blown your quota, either you stop voting, or you redistribute your votes differently itâs up to you to choose what you find most interesting to develop for yourself.
We can add voting credits in the future, but for now, given the fairly low number of features proposed (28 at the time of writing these lines), that means you can vote for 20% of the features, which seems coherent.