我可以将多种类型分配给单个分类，但这并不太有效：
- 如果启用了 support+mark，所有帖子都会被标记为未解决，用户无法指定他们有一个支持请求
- 所有帖子都显示“0 票”，即使用户可以将帖子标记为可投票（应该只向选择加入此功能的用户显示 0 票）
- 当我启用事件时，分类会被一个巨大的日历取代，虽然这在某些情况下可能没问题，但对于普通讨论组来说，一个带有小型日历侧边栏小部件会更实用，这样我只能将少数帖子标记为具有日期。
1 个赞
在“已解决”、主题投票和活动插件成为类别类型之前，你是如何使用它们的？虽然为类别配置这些插件的过程发生了变化，但我记不清这些功能本身是否有过改变。
你以前也在类别上使用过这些插件吗？还是说你只是第一次尝试使用它们？我很好奇，以前用户是如何表明他们的主题是支持请求的。
1 个赞
我只是在试用一下，想设置一个“产品创意投票”版块。我希望采用话题投票和私密评论的形式，但效果最好能再好一些。我现在知道了，系统并没有提供专门的版块来强制实现这种形式。不过反过来想，我也可以把它们和普通帖子混在一起，这样也不错。只是需要培养用户真正去使用这些功能（或者允许版主将某个帖子转换为创意投票帖……嗯）。
我也想到了类似的想法，但只专注于支持。功能类帖子可以接受投票，而技术类帖子则会收到解决方案。
创建两个类别对用户来说适得其反；目前，我打算暂时不启用它们，原因正是如此。
梦想：发布时会有一个初始表单对帖子进行分类，然后每个帖子都会获得相应的功能 
我觉得你可以用标签来实现。这样，你就可以基于 #question 标签启用相应的解决方案，并通过 CSS 隐藏这些主题上的投票功能，就像 Meta 上 feedback 主题所做的那样。
你还可以将其与 form-templates 标签结合使用，以便在标签选择时提供帮助。
哦，你真的可以根据标签来创建解决方案类型吗？比如“标记为支持问题”？这样讨论帖就不会显示“我也遇到了”或“标记为已解决”按钮了，那可就太棒了。
我赞同这种融合，某些主题应该同时提供“我也一样”选项和投票功能。我认为应该可以切换，以启用两者、其中一个或都不启用。
我不确定该如何妥善处理，但这个目的在这里确实得到了支持。
有一个 enable_solved_tags 设置。但我不确定它是否支持“我也是”按钮。
新的报告工具似乎仅限于按类别配置已解决插件。这让我怀疑其他最近的功能是否也受到了影响。
1 个赞