Changing How We Work and Accept Feature Requests

[tankerkiller125]

As the project community continues to grow the number of feature requests do as well. This is resulting in the Github issues being 90% feature requests with a few bugs, and a few epics and makes it somewhat difficult for us to track and remember everything going on. As such starting today we're changing how we accept Feature Requests.

Starting a few minutes ago from this posting we've re-configured our GitHub issues config to to only accept bug reports. With a link to the Github Discussions Ideas category for feature requests. Going forward all feature requests should go into this discussion category.

Additionally, we've updated the config to link to our translations portal, and support discussion category and disabled blank no-template issues to encourage everyone to use this change.

Finally, we're going to start converting existing feature requests we're not actively working on into discussions. Later, when we or a community member decides to commit to developing a feature we'll generate an issue from the discussion for development tracking.

This change will help us keep track of things, and additionally hopefully reduce the number of duplicate feature requests we encounter. Plus because discussions have clearly marked and visible upvoting it can help us truly determine how popular a feature request is.

[tankerkiller125]

Additional note on this, issues that already had bounties have not been converted. This is to preserve the bounties on them.

[tioan]

Unfortunately, I don't like the new approach at all. In my opinion, it would be better to continue using issues, as these can be linked in changelogs etc., but categorize them using labels and “standardize” the creation of new issues using issue templates.

[tankerkiller125]

An issue will be created from the discussion when someone (be it us the maintainers or a community member) chooses to work on implementing the feature.

At the end of the day, as maintainers we're the ones who have to use the issues list, and prioritize features. Github Discussions frankly just has a much better interface for prioritizing feature requests given the clear and simple up arrow functionality and the ability to sort by said up arrows. I'm sorry your not a fan, but as maintainers all three of us agreed that this system would (at this time) work better for how we work.