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
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:
Codidact is small, as is our team. Our development team is even smaller. That means that time, especially dev time, is a …
11mo ago
I've updated the feature-request tag description to incorporate the suggestions in this answer. Thanks for putting that …
11mo ago
EDIT after follow-up comments thread (where links for tags tab and status are given) and answer: The solution proposed h …
11mo ago
Post
EDIT after follow-up comments thread (where links for tags tab and status are given) and answer: The solution proposed here already exists so it is irrelevant. The pro/cons part could still be used to compare the current solution and the solution with a "status page" (#1 in the table below)...
Simple solution partially fulfilling the objectives
Here a solution that would easily (from dev point of view) answer a large part of the specifications set in the current question:
- Create 3 new status tags: pending, implemented, rejected (maybe these tags should be usable only by staff)
- (colored tags could be interresting: orange: pending, green: implemented, red: rejected).
- Then the user can obtain the list of all feature-requests with the search bar and filtering by tag status, vote counts, date, etc. (which will look approximately the same as the "feature list" in the proposal in the current question).
Solution comparison
| # | Solution | Pro | Cons |
|---|---|---|---|
| 1 | "feature request status page" | Quick visibility of all feature requests and their current status | More dev work |
| Possible link to the "announcement post" if implemented | Accessibility: how to find this page? | ||
| Possible advanced filtering of the request list | |||
| 2 | Tags solution | Easier to implement | feature-request status less visible (users need to know the tricks to get status info) |
| Less concatenated view with less information related to feature-request specificities (because the method uses the search system common to all Q&A) | |||
| Less room for improvement later |
3 comment threads