Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Codidact Meta!

Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Comments on A feature-request status page

Parent

A feature-request status page

+6
−0

Motivation

I have the feeling (obviously biased ;) that some feature requests get forgotten over time. I absolutely do not claim that it is anyone's fault but that they naturally become less visible over time because they are less active (it's a guess).

Based on this assumption, the question is: how to improve/maintain the visibility of feature-request posts over time?

(Of course we can also consider that a non-active request means that nobody wants it... But is the feature-request enough visible to be active?)

Proposal

A "feature request status page" could be created on meta (maybe more like an article than a question: i.e. no possible answer) which list all feature-requests and give some info about them, for e.g.:

  • Status: pending, implemented, implemented (partially), rejected.
  • Vote counts (with the possibility of voting directly on this page EDIT after follow-up comment it seems better to avoid voting on the status page in order to encourage user to see/participate in the entire discussion before voting).
  • Link to the "announcement post" if implemented or the GitHub issue if pending (if relevant).

Here an example of what could be a feature-request list: example of what could be a feature-request list

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

3 comment threads

Potential problem with in page voting (2 comments)
GitHub issues (1 comment)
Related Features (2 comments)
Post
+8
−0

Codidact is small, as is our team. Our development team is even smaller. That means that time, especially dev time, is a very precious resource that we have little of. Something like this requires a fairly significant time investment both in development and in keeping up to date; I'm not convinced that it would be worth that investment at the moment.

Here's what we do have, some of which you may have missed, that might help you keep an eye on the status of various feature requests:

  • Filters. I've set up a custom filter for open feature-requests on my Meta home page so that I can see at a glance what's open. It looks like this:

    Filter settings; set to include tags "feature-request", and exclude tags "status-completed, status-norepro, status-planned, status-bydesign, status-declined, status-deferred".

  • Tags. As you might have gathered from that filter setup, we use status tags on Meta to indicate where things are holding. There are a fair few, but the major ones are status-completed (done), status-planned (we're planning to do this at some point), status-deferred (idea is doable but we don't have time/resources right now), and status-declined (won't or can't do this). You can browse these tags to get an idea of where things are.

  • GitHub. Any feature request that our team thinks we should do or are planning to do gets logged as an issue on our GitHub repository — this is what our devs look through for things needing to be done.

The final thing you might encounter from time to time is feature requests or bugs that we've completed or fixed, but aren't on the live site yet because they're waiting to be deployed when we next have time.

I hope that gives you a few tools to keep an eye — if you're looking for where a specific feature request is holding, feel free to ping one of the team in Discord, and if you have ideas for how we can improve these tools/processes we'd be happy to hear them.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

2 comment threads

It might be possible to have categories for meta tags? (4 comments)
Thank you very much for this answer, I will definitely use this! When you say that you lack time to d... (2 comments)
It might be possible to have categories for meta tags?
Wicket‭ wrote over 1 year ago · edited over 1 year ago

I have not analyzed the feature request situation yet, so I have no idea how many there are, etc., but I was wondering about having categories in Codidact Meta for each meta tag when they reach enough activity.

After writing the above, I realized that having a category for a meta-tag might make the meta-tags to be no longer required and will prevent having posts ambiguous "meta-tagging" (using two or more meta tags in a single post).

trichoplax‭ wrote over 1 year ago

When you say "meta tags" do you mean "status tags" (the ones that show in red on the tags tab)? These can only be applied by a moderator and I've never seen a post with more than 1 status tag applied.

Wicket‭ wrote over 1 year ago · edited over 1 year ago

I was referring to "discussion", "feature-request", "bug" and "support" only (obligatory tags?).

trichoplax‭ wrote over 1 year ago

I understand now. I'm not sure what to call them, but each Meta question requires at least one of them.

Although very few questions have more than one of these required tags, some questions change between them as more information becomes available, which would require moving between categories if they were categories instead of tags. This doesn't rule out the possibility, just something to consider.

In deciding whether it is useful to separate into categories, I would probably ask questions like "how often would people want to see only 1 of these categories at a time?" and "are filters more useful as they allow viewing 2 or 3 of the 4 tags, rather than just 1 category at a time"