28

In 2020, we instituted a new process for escalating and responding to Meta feature requests and bugs. As we announced a few weeks ago, we are doing a ticket smash today to work through the backlog of posts escalated under that process without a response.

You may see a number of older posts surface on the All Questions or Top Questions pages as we update their tags. You may also see a number of posts marked as and , simply because they do not line up with our Q1 roadmap that defines what we are actively working on.

Improve this question
7
  • 12
    Front page being Yaakoved in 3, 2, 1...
    – Luuklag
    Commented Feb 19, 2021 at 17:14
  • 1
    Will this ticket smash also include posts tagged status-review before the escalation process was created in March 2020?
    – Sonic the Anonymous Hedgehog
    Commented Feb 19, 2021 at 22:16
  • 2
    @SonictheCuriouserHedgehog It only includes status-review posts AFTER the escalation process was created. The escalation process creates tickets in our ticketing system, and tickets are what's driving the ticket smash
    – Anita Taylor StaffMod
    Commented Feb 19, 2021 at 22:27
  • is this effort limited only to MSE? If not, is the plan to only cover MSE and MSO? Is anything like that planned for smaller site metas in the foreseeable future?
    – gnat
    Commented Feb 20, 2021 at 8:08
  • @AnitaTaylor would any regular post edit of a tag that has a status-review tag that was added before the escalation system was put in place add it as a ticket to your system? Or does your logic only check for the addition of the status-review tag?
    – Luuklag
    Commented Feb 20, 2021 at 8:47
  • 6
    @luuklag Yaakov has Fridays off, so I missed all the fun
    – Yaakov Ellis StaffMod
    Commented Feb 20, 2021 at 18:17
  • If I had a diamond I'd add some status-reviews just for you @YaakovEllis. Hope you enjoyed your day off though.
    – Luuklag
    Commented Feb 20, 2021 at 18:39

6 Answers 6

Reset to default
34

I noticed that a lot of prior requests are being tagged on the grounds that they're not part of the current Q1 roadmap.

Once the roadmap's timeline is over, will such requests be automatically considered for future timelines, or will new reconsideration requests have to be filed for those requests in order for them to be considered?

If so, will "the mentioned roadmap has passed" or "can this please be added to a future roadmap" be valid rationales for having the requests reconsidered?

(For clarity: at least a couple of the requests that were marked declined with this rationale were things I wanted to see implemented. I was planning to post reconsideration requests for those once the timeline was over, but wanted to ask first if that was necessary.)

Improve this answer
5
  • 2
    I'm not sure, but I think the difference is a subtle distinction in the staff messages. If you check the linked answer in my post, roughly: "ticket was put on backlog/todo-list" is what "status-deferred" probably means, while if it's not even put on the todo-list right now it's "status-declined" for the time being. But apart from having a staff message there's no obvious way to distinguish between the 2 kinds of "status-declined" from the tags alone.
    – bad_coder
    Commented Feb 20, 2021 at 1:29
  • 8
    I also find it a poor status tag to use vecause something isnt on the roadmap for the next 6 weeks, as that is how long Q1 lasts. Status-deferred would be the better tag, unless SE sees no merit whatsoever in a proposal, and that once work on the area of interest starts it woypdn't even be considered. This abundant use of status-declined is a slap in the face to all thise good proposals.
    – Luuklag
    Commented Feb 20, 2021 at 14:30
  • 5
    @bad_coder that's right. We used 'planned' for things in active development or discovery, deferred for things we think we'll be working on next, and 'declined' for things that don't have any plans at the moment.
    – Des StaffMod
    Commented Feb 20, 2021 at 17:38
  • 10
    @Des could you ammend the tag wikis for status declined and deferred then to make them reflect their current usage. As you clearly re-defined the meanings of the tags.
    – Luuklag
    Commented Feb 21, 2021 at 8:29
  • 10
    @Des- or better yet, add more red status tags that impart better information. [status-active-development] (currently being worked on, replace the current usage of 'planned'), [status-planned] (on the roadmap for future work but not currently under development), [status-backlogged] (lower priority or not on current roadmap), [status-deferred] (needs further investigation/discovery but will eventually be considered). etc
    – Robotnik
    Commented Feb 24, 2021 at 12:48
32

I'm rather concerned about this use of the tag, as it implies a finality that I do not believe was intended but which will definitely be read. From the tag wiki (emphasis mine):

A feature request or bug report is considered declined if the report is reviewed and the site developers disagree that the feature should be implemented or the bug should be fixed.

...

In the case of feature requests, this usually comes up if the request is counter to site philosophy, if the request is attempting to change behavior that is intentional or even encouraged by the system, or if the request creates greater complexity or problems in the system than it successfully solves.

Rather than outright rejecting the feature request, it seems to me that your intent here was to use this as a "status-declined-but-only-for-now", to indicate that yes, it was reviewed, but no, it's not on the table; a role probably better suited for :

A feature request or bug with this tag is something that has been evaluated as positive on potential, but is not present in the current work timeline.

Insofar as you want to keep for things that only have an actual chance to be moved on in the foreseeable future, I think the best alternative would be to simply remove the tag from the "declined-for-now" requests entirely. This, at least, communicates that the feature request hasn't been outright rejected, and may still be considered if escalated for review in the future at a better time, but simply isn't on the table right now.

Alternatively, perhaps you can create a new tag (?) to cover this use case, which would mark a reviewed request as being viable (or at least still worth considering) while also refusing to move on it at this moment.

Improve this answer
8
  • 1
    While I agree, maybe it is better to update the tag wiki to reflect the current situation.
    – Shadow Wizard
    Commented Feb 21, 2021 at 7:03
  • 11
    @ShadowWizardisVaccinating I disagree, mostly because right now, "declined" is clearly defined, and changing it to mean "declined and/or deferred, but not really deferred-deferred" just adds ambiguity to both tags rather than removes any.
    – goldPseudo
    Commented Feb 21, 2021 at 8:00
  • No, what I have in mind is taking the canonical "Based on our current roadmap, this isn't work that we will take on, as it doesn't coincide with functional areas that we plan to improve in the near future" they now post on the rejected bugs/requests and using it in the wiki somehow, but I'm not sure of the proper wording yet, plus it might be bigger than me. (i.e. better done by SE staff.)
    – Shadow Wizard
    Commented Feb 21, 2021 at 8:26
  • This. Exactly this! I made comments about this as well, but got no satisfactory response there.
    – Luuklag
    Commented Feb 21, 2021 at 8:26
  • 2
    meta.stackexchange.com/questions/361140/… here another reply is from Des, explaining their plans.
    – Luuklag
    Commented Feb 21, 2021 at 8:28
  • 7
    @ShadowWizardisVaccinating Changing the wiki to reflect the current usage is fine, but you also have to consider all the existing questions that are already tagged with status-declined under the original definition. If going that route, it would make more sense to create an entirely new tag (status-somedaymaybe?) than to double-load the existing one.
    – goldPseudo
    Commented Feb 21, 2021 at 8:47
  • @goldPseudo good point about past usage, but still, not sure it justifies whole new status tag. Worth a new discussion, feel free to start one. :)
    – Shadow Wizard
    Commented Feb 21, 2021 at 9:05
  • 2
    @ShadowWizardisVaccinating I agree a new status tag is much more meaningful here than modifying an existing tag that has been in use for a decade.
    – Mast
    Commented Feb 27, 2021 at 15:24
23

On the one hand, I very much appreciate seeing staff interact with our per-site metas once more, and actually giving us some closure on feature requests—even if it is to decline them. I see this as staff putting in work to get the community/staff trust and interaction back to where it should be and used to be.

On the other hand though, on the two sites I'm most active on, the feature requests that were declined were among those sites' biggest pain points and ones we'd been waiting to see resolved for years. They weren't just as in they have “merit to consider, but will not be implemented or fixed in the near term”, they were , as in this simply indefinitely will not happen (GoldPseudo raises this concern here).

The staff responses gave no explanation other than that they're not a current priority. These are more serious issues that warrant a fuller explanation if they're simply never going to happen. It feels like there's still some kind of breakdown here, and personally it feels like it's the following: (1) staff do not know our community's priorities and pain points in order to understand when a more full consideration and explanation might be needed, (2) staff aren't given the resources to take the time to engage with us, learn those things, and make more thorough evaluations and deliver more thorough explanations, and/or (3) our communities and their pain points just don't really matter and we don't know why.

March 24th update: One of the above-mentioned issues, the one on Board Games Stack Exchange, has been given another look and is now . The community will be very appreciative of this fix.

Improve this answer
1
  • I have a bet in Vegas that it's number three, there at the end. 😒
    – KorvinStarmast
    Commented Feb 27, 2021 at 23:44
8

This sounds good, so we now have some feedback which things may get addressed at some point, and which likely won't.

However, I noticed that there are currently more than 180 questions, many of them quite old. Do you also plan to do a ticket smash for those? ;)

Improve this answer
4
  • 11
    We need to crawl before we walk, so initially our focus will be on getting to the point where we respond to status-review in a timely manner. After we've mastered that, we'll consider how to handle backlog of status-deferred
    – Anita Taylor StaffMod
    Commented Feb 19, 2021 at 18:22
  • 4
    @AnitaTaylor Will questions tagged status-deferred automatically be getting attention when they're related to a topic that could be listed here? Would it make sense for people to flag those again for status-review if they're currently status-deferred but listed on that post, and for moderators to again put a status-review tag on those?
    – Tinkeringbell Mod
    Commented Feb 19, 2021 at 19:03
  • 4
    @Tinkeringbell When we list a topic we'll be focusing on, mods should feel free to put a status-review tag back on posts that relate to that specific topic
    – Anita Taylor StaffMod
    Commented Feb 19, 2021 at 20:28
  • 3
    Related: meta.stackexchange.com/questions/357341/…
    – Sonic the Anonymous Hedgehog
    Commented Feb 19, 2021 at 22:15
5

This might prove useful....

enter image description here

Improve this answer
4
  • 12
    Oy! Weren't you supposed to give that back when you stepped down?
    – terdon
    Commented Feb 19, 2021 at 16:30
  • 9
    @terdon I was keeping it for a time of true need, to be passed onto the worthy.
    – user960635
    Commented Feb 19, 2021 at 17:13
  • 2
    i.sstatic.net/v3RLN.gif
    – Rand al'Thor
    Commented Feb 19, 2021 at 19:12
  • 4
    "He who holds this hammer shall have the power of nine shogs" Sounds legit
    – Machavity
    Commented Feb 19, 2021 at 20:23
1

A bug report I posted just received an answer by @JonChan♦ in the ongoing ticket smash, marking the bug for the time being.

As I posted other open bug reports that may receive answers by staff, I want to ask if it's better that we mark the answers as accepted for now?

Improve this answer
5
  • 7
    You never need to mark an answer accepted. I would recommend avoiding it except in cases where you're pretty confident that the next reader will want to read that answer first
    – Shog9
    Commented Feb 19, 2021 at 18:12
  • @Shog9 that is interesting, I think of accepted as green on the search results :|
    – bad_coder
    Commented Feb 19, 2021 at 18:15
  • 3
    That's an unfortunate implementation detail that doesn't quite capture what's really important I'm afraid; what you'd usually want when searching is to know whether or not anyone had looked at an answer & found value - so, upvoted or accepted. There's an operator for that, but the UI is not great. Google, of course, kinda underweighs both.
    – Shog9
    Commented Feb 19, 2021 at 18:29
  • @Shog9 the UI is real eye candy, I like it. Folks often say Google is better, but I think that's only true if you're searching for a direct-hit canonical. The real underrated gems require tag researching the corpus (that's where the green check mark helps a lot), and for that SO search is excellent (a lot like GitHub.)
    – bad_coder
    Commented Feb 20, 2021 at 1:17
  • 2
    Not sayin' it ain't pretty - nothing wrong with some green to dress up a page 😁
    – Shog9
    Commented Feb 20, 2021 at 3:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .