Proposal: Converting feature suggestion issues into discussions

[tbabej]

Over the years, keeping the TW backlog in check has always proven to be a bit of a challenge. Several years ago I remember this being a month-long chore where my only TW activity was grooming the backlog. One of the problems is the large number of valueable (yet perhaps not immediatelly actionable) suggestions that have accumulated over the years.

I am once again trying to dip my toes in trying to get things a bit more sorted in the issue backlog and would like to propose us adopting the following policy:

Issues tab should only be used to track:
* (a) bug reports
* (b) "accepted" features

Feature suggestions and requests should be instead discussed in a dedicated "Feature suggestions" discussion subforum. Existing or future issues that are in essence feature suggestions will be converted to discussion topics in this forum.

The motivation behind this is to slim down the tracker to immediately actionable items, with the eventual goal of reaching 0 (or close to that) when a new release is being cut. Additionally, this would help with prioritizing the feature suggestions based on user interest - as discussion topics, unlike issues, can be upvoted and sorted by the number of votes.

Once a feature has been fleshed out in the discussion, and has the backing of someone who would implement it, it would get an associated issue in the backlog. Issues for features that are initiatives of core developers would not have to necessarily go through this process when it doesn't make too much sense (just to avoid adding overhead for issues that are tracking necessary improvements / followups).

[djmitche]

I'm all for this!

[ryneeverett]

I'm fully supportive of requiring issues to be "actionable" but I think the requirement of "the backing of someone who would implement it" goes too far.

1. In a volunteer-based OSS community there's a lot of hesitation to publicly commit to doing work.
2. There would be no unassigned actionable feature request issues which would discourage new contributors.

Also, how do you envision "acceptance" of a feature request working? Does a committer delegate the opening of feature request issue or do they open it themselves? It seems to me like it's generally harder to get committers to agree that a feature is good idea before they see the implementation and that contributors who want to follow the issue-followed-by-a-pull-request model are likely to feel bogged down in the acceptance process rather than just implementing it and opening a pull request like they normally would.