Bug Reports category

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).

posted over 4 years ago

CC BY-SA 4.0

Sigma‭ staff

3 14 58 15

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.

posted over 4 years ago

CC BY-SA 4.0

luap42‭ staff

17 68 568 98

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"?

posted over 4 years ago

CC BY-SA 4.0

4y ago

Lundin‭

30 57 412 51

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.

posted over 4 years ago

CC BY-SA 4.0

user1306322‭

1 3 0 1