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
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...
Answer
#6: Post edited
**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
**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
**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
**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
- # 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
# 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|