I think there are (at least) two aspects to consider regarding feature requests.
- It’s nice to have a (public) roadmap where planned features are listed in order or priority and, as much as possible, with an indication which release they are planned for. I suppose that is what you mean by “feature plan”.
- Before feature requests end up on the road map, they should be discussed. Even very straightforward and simple suggestions can often be tweaked to become even better. Others are may require user input in order weigh different options against each other and to understand their implications. This is what topics in the #feature category are for. And since multi-topic topics are difficult (if not frustrating) to read, we try to keep them focused on a single topic (not only in the #feature category) and encourage multiple posts rather than one.
That said, it is, sometimes difficult to determine whether something is a single topic with multiple sub-points or multiple topics. To decide whether A and B should be in a single topic or in multiple topics, it’s probably a good idea to ask yourself whether separate discussions are likely to include similar questions or even whether discussing A will inevitably lead to discussing B (or vice versa).
If in doubt, start with multiple topics. It’s easy to merge topics into one, it is impossible split a topic into separate topics once there is a reply that refers to more than one of these topics.
Oh, and perhaps there is a third aspect:
- When users read about a feature request, they should be able to see whether this feature is already #implemented, #planned or whether it has been rejected (#not-planned). Tagging posts in this manner will also make it easier to compile a roadmap. Since @gchen is the one to make these decisions, he should apply those tags.
ed whenever they are implemented.
).