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.

Post History

50%
+0 −0
Q&A A feature-request status page

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

posted 1y ago by zetyty‭  ·  edited 1y ago by zetyty‭

Answer
#6: Post edited by user avatar zetyty‭ · 2023-06-29T05:48:40Z (over 1 year ago)
change links to follow-up comment
  • **EDIT after follow-up comments ([here](https://meta.codidact.com/comments/thread/7744#comment-20294) and [here](https://meta.codidact.com/comments/thread/7744#comment-20295), where useful links for tags tab and status are given) and [answer](https://meta.codidact.com/posts/288693/288695#answer-288695):** 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|
  • **EDIT after [follow-up comments thread](https://meta.codidact.com/comments/thread/7744#comment-20294) (where links for [tags tab](https://meta.codidact.com/categories/3/tags) and [status](https://meta.codidact.com/categories/3/tags?q=status) are given) and [answer](https://meta.codidact.com/posts/288693/288695#answer-288695):** 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|
#5: Post edited by user avatar zetyty‭ · 2023-06-28T06:43:28Z (over 1 year ago)
adding comment links
  • **EDIT [after follow-up comment](https://meta.codidact.com/comments/thread/7746#comment-20297) and [answer](https://meta.codidact.com/posts/288693/288695#answer-288695):** 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|
  • **EDIT after follow-up comments ([here](https://meta.codidact.com/comments/thread/7744#comment-20294) and [here](https://meta.codidact.com/comments/thread/7744#comment-20295), where useful links for tags tab and status are given) and [answer](https://meta.codidact.com/posts/288693/288695#answer-288695):** 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|
#4: Post edited by user avatar zetyty‭ · 2023-06-28T03:57:42Z (over 1 year ago)
removed author name in answer link
  • **EDIT [after follow-up comment](https://meta.codidact.com/comments/thread/7746#comment-20297) and [ArtOfCode's answer](https://meta.codidact.com/posts/288693/288695#answer-288695):** 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|
  • **EDIT [after follow-up comment](https://meta.codidact.com/comments/thread/7746#comment-20297) and [answer](https://meta.codidact.com/posts/288693/288695#answer-288695):** 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: Post edited by user avatar zetyty‭ · 2023-06-25T11:32:34Z (over 1 year ago)
Typo + reformulation of th 1rst cons of solution #2 regarding visibility status
  • **EDIT after [after follow-up comment](https://meta.codidact.com/comments/thread/7746#comment-20297) and [ArtOfCode's answer](https://meta.codidact.com/posts/288693/288695#answer-288695):** 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" (nb 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 "annoncment 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 (mainly for new users) |
  • |||| 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|
  • **EDIT [after follow-up comment](https://meta.codidact.com/comments/thread/7746#comment-20297) and [ArtOfCode's answer](https://meta.codidact.com/posts/288693/288695#answer-288695):** 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|
#2: Post edited by user avatar zetyty‭ · 2023-06-24T19:06:29Z (over 1 year ago)
EDIT to say that this solution is irrelevant after follow-up answer + adding cons for tags
  • # 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 "annoncment post" if implemented| Accessibility: how to find this page?|
  • |||Possible advanced filtering of the request list ||
  • |2|Tags solution|Easier to implement| 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|
  • **EDIT after [after follow-up comment](https://meta.codidact.com/comments/thread/7746#comment-20297) and [ArtOfCode's answer](https://meta.codidact.com/posts/288693/288695#answer-288695):** 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" (nb 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 "annoncment 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 (mainly for new users) |
  • |||| 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|
#1: Initial revision by user avatar zetyty‭ · 2023-06-24T06:09:11Z (over 1 year ago)
# 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 "annoncment post" if implemented| Accessibility: how to find this page?|
|||Possible advanced filtering of the request list ||
|2|Tags solution|Easier to implement| 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|