Milestones / Status as subcategories added for features and bugs categories

As a newbie joining the discourse community, it is extremely difficult to understand the status of features and bugs reported. If the topic is closed, may be we can assume it is implemented.

Why can’t we add sub-categories under features / bugs with versions like 1.2, 1.3, 2.0, later and add them to relevant topics.

Some project teams maintain them in github / trello…we can easily define that in sub-categories.

It will really help anyone to understand the priorities of the discourse team before pushing them for features. In the present scenario, unless a community member tells about the priorities or link multiple roadmap topics a newbie has no clue.

we can use tagging for some of this stuff as soon as @eviltrout has the tagger plugin working. similarly we can have a priority-high / low etc tag

I am generally not interested in the kind of granularity you are speaking of. If it is on the near term roadmap it will be a bullet point in one of the posts in the the /releases category. If it is not, then we get to it when we get to it; looking too far in the future is not practical.

If you want to influence that, pay for a hosting plan, and know that we give feedback from our enterprise customers the most weight: http://www.discourse.org/buy

@sam that sounds right. Thanks

@codinghorror Thanks for letting me know about the rules followed here. What I stated is one of many best practises in opensource communities… obviously you can ignore it.

Anyway, I will add the suggestions below based on your remarks…

Feature topics which are already in the roadmap can atleast be marked with ‘versions’. Other topics can be added as ‘later’. This is to avoid the back and forth between a newbie and a community members (finally pointing out the roadmap topics).

1 Like