Sign Up Sign In

Bug Reports category


Meta should have a dedicated category for bug reports, to increase the chance that users will pile onto an existing bug report rather than create new ones.

Even people who can't be bothered to search, are on a platform where searching is painful, or who search ineffectively, might notice a dup report on the first page of a bug category.

Why should this post be closed?


Could you elaborate on why using the tag to see just bug reports doesn't address the problem? Thanks. Monica Cellio about 1 month ago

Exhibit A: my bug report from last night embarrassingly closed as a dup. Aliza about 1 month ago

Even with a dedicated category, there's no way we can expect people to search through every post just in case it might have been reported before... duplicates happen, they're not a bad thing - and they deliberately don't count against you in any way. ArtOfCode about 1 month ago

Even people who can't be bothered to search, are on a platform where searching is painful, or who search ineffectively, might notice a dup report on the first page of a bug category. Aliza about 1 month ago

4 answers


I'd disagree here, because I think this is not, how categories should be used.

First of all, there shouldn't be too many categories, because the UI becomes confusing, possibly problematic on mobile and it becomes IMO harder to find stuff. This can already happen sometimes at 3-5 categories, but it's probably going to be worse, the more categories we have. Also, categories can't really be removed, once added, hence I'd be careful with adding ones you don't really need. While it is possible to move posts between categories, it requires either database access or manually going to a special "tools" menu for every single post.

I see categories as a way to separate different types of content (not neccessarily post types). In my opinion, a Q&A "thread" is something different from a Challenge "thread" or a Blog or a Wiki. I'd also consider a Meta post something inherently different from a Q&A post. They serve different purposes to visitors of the site. Some inform more generally, some are for specific problems and others are a bit more fun. All are about the underlying community, but they address different interests of it.

On the other hand, bug reports are not something completely different in my opinion. As with feature requests and support questions, they are about "issues" or unclear stuff you came across when using the site.

In the same way, most [discussion]s we have here, don't really seem to me to be community-policy discussion (which should also be mostly in the per-site meta communities), but rather pre-request discussions about new features and "mistagged" support requests. Just very few are real discussions IMO, so it doesn't really make sense to separate them.

Furthermore, there are ways to group posts based on their content: tags. We have several nice features for them, including tag hierarchies, "topic" and "required" and "mod-only" tags. This is IMHO sufficient for grouping posts right now.



We do technically have a dedicated bug reports channel on Github.

Rather than making a separate category on Meta, it might make more sense to keep all bug reports relating to the software on Github. Eventually others might self-host Codidact instances, and having a central repository of known issues for developers to be aware of would be preferable to having them simply buried as Meta posts somewhere on the canonical Codidact instance.

The downside to using the Github issues tracker is that some Codidact users may not have or want an account on another site. We could work around this by having a "submit an issue" button on Codidact and automatically posting those issues to the tracker, but that would likely be a hassle for the developers to set up (correct me if I'm wrong).


It is more than just "an account on another site". Some existing users, and I expect many future users, will be relatively non-technical types. They may be experts on photography or cooking but not programmers/developers. As such, posting to Meta will be easy (same as the communities they are using) but Github will be quite foreign. In addition, the Meta Codidact instance, at least at the "bug & development tracking" level (as opposed to policy issues) can function for independent instances manassehkatz about 1 month ago

as well. If a group of people want to spin up their own site, either to host a "private" group or in order to have policies that differ from ours, they can still come here to post bug reports or feature requests, and then update their own instance from the master instance on Github when changes are implemented. manassehkatz about 1 month ago


I agree. We could benefit from having:

  • One category for discussing site/network use and features (current Q&A)
  • One category for plain bug reports.
  • One category for support requests and beginner help.
  • The existing categories for site proposals and blog/info.

There are all non-related and we know from (SE) experience that it doesn't do much good to group them together into one single, unholy mess.

For example, it doesn't make sense to have meta voting on a support request - what does that even mean? "I don't agree that you are having this problem"?


In the long run, voting is not an unreasonable way to prioritize bug reports and raise the visibility of recurring support issues. Aliza about 1 month ago

A downvote on a bug report can mean various things, like "RTFM, moron", "it shouldn't be bothering you, get over it", or "maybe it's technically broken, but this is such a silly nit-pick that I wouldn't want to see the developers waste their time even reading this request". Olin Lathrop about 1 month ago

I have up voted this A because my immediate reaction was to favour a separate category, and I appreciate the clarity of your expression. (Plus your last paragraph made me laugh.) However, I disagree with "Bug" as a separate category because I believe it is too much to expect general users to distinguish between bugs, feature requests and even sometimes general support. IMO, tag edits should be more effective. pnuts 25 days ago

Regarding the meaning of voting on a support request, for the time being at least I do so on the basis of the quality of the Q. That is how well researched (eg not a duplicate) and presented (clarity, concision, layout, spelling etc.) and whether or not details provided at the first attempt are reasonably likely to be sufficient for a definitive A. pnuts 25 days ago


I think a purely technical bug tracker could be useful, for things that should be working as agreed upon by meta discussions, but are malfunctioning at the moment.


Sign up to answer this question »