11

Sometimes, I've come up with a suggestion for a feature change to be made to the Stack Exchange engine. Based on several guideline posts on how to write well-received feature requests, I've come up with a fairly strong argument for implementing the feature that is likely to be received positively by the community.

However, as part of my research, I found that someone else already requested the same feature. That prior request, though, made quite a weak argument in favor of making the change, which has been quite disagreed by the community. It has received a score negative enough to not show on the home page when bumped, and the comments and/or at least one answer explain why the author's arguments for implementing the change don't concord with community consensus or SE principles. On the other hand, my argument contains several points not brought up in the prior request (or they were raised in comments but got buried in other comments and thus never seen).

As per usual Meta community consensus, it isn't a good idea to post a new request, as it will be closed as a duplicate of the prior request. The general action to bolster a feature request with new arguments for implementation is to post an answer to it with my strong argument, but it's generally a fruitless action if the original request was received negatively, as if its score is low enough it will never get seen on the home page, and even if it's not negative enough, users aren't likely to click on questions that have negative scores. The presence of the prior weak request essentially hinders my ability to properly present my stronger arguments for the feature.

What can I do if I have strong arguments for implementing a feature change that haven't been brought up before, but a request for the exact same change that makes a weak argument and is negatively-received already exists?

One thing I can think of is to try and get the SE team to officially decline the prior request on the grounds of the disagreeing answer(s) or comment(s), which makes it possible to make a reconsideration request with the new, strong argument, but I don't think it's necessary to involve the community team for such a small matter.

Improve this question
1
  • 5
    In theory older request can be closed as duplicate of a newer request. There are no rules, it's purely case-by-case, but it's possible. So post your own version, and if it's really better and more clear, the other request might get closed as duplicate of it instead of the opposite.
    – Shadow Wizard
    Commented Jul 17, 2022 at 6:26

3 Answers 3

Reset to default
5

Reading over your request, I thought this was already the established policy; in the reconsideration request post you link, the answer states (emphasis mine):

I'd expect that you should be able to request features after a period, BUT you need to bring something to the table to identify why you think the situation has changed, why is now the right time for the feature, for the community. Like anything, you can't just reissue the same request, without expecting it to be declined again or closed as a duplicate of the earlier request... Whether or not that's possible of course depends on the reason (if any) given for the feature being declined...

You should also indicate in the request that you have seen and acknowledge the old post and why you think it's important enough to have posted a separate request (as pointed out by Grace Note)

If we break this down, here's, in my view, what we get as the rules for such a request:

You can indeed resurface an old request, IF:

  1. You have something new to bring to the table that the old request did not have.
  2. The situation surrounding the request has changed, and your new request adequately identifies this change.
  3. You can present reasoning that now is a good time for the request.
  4. You acknowledge the existence of older feature request.
  5. You adequately express why the new request is important and distinct from the former one.

I don't see any reason why a new request which has a new, well supported/ good argument cannot be posted to supersede an older request with a poor or outright bad argument. Obviously it's up to the community to decide whether the new request is worth listening to in light of the old one (and whether it adequately meets the guidance above), but I think that needs to be taken on a case-by-case basis, like every feature request.

Obviously if someone thinks their argument is good and is just wrong about that, then that request will have a different reception than one that actually does bring a great new argument to the table, but I see no reason why they shouldn't be allowed to try to bring that argument to begin with.

If the worst outcome of posting a request is that it gets downvoted and/ or closed as a duplicate, then as long as a user isn't incessantly posting terribly-received requests, then I don't think there's much to lose by posting such a request.

I think that, at the end of the day, if Meta is presented a good argument, generally it will be inclined to listen. Just don't spam requests, especially poorly thought out ones.

Improve this answer
6
  • I can't have a positive outlook on this, my prediction is we'll see post after post "stewing in its own juices". If a determined poster doesn't succeed one week they'll rephrase the arguments next month and so on... (This also places a burden on readers and reviewers, they'll have to spend time evaluating variations on the same thing.)
    – bad_coder
    Commented Jul 18, 2022 at 17:32
  • My guess is the majority of these 11k posts [feature-request] hasaccepted:no -[status-completed] closed:no -[status-declined] need to be closed for one reason or another.
    – bad_coder
    Commented Jul 18, 2022 at 17:44
  • 2
    @bad_coder I guess I just don't think that more requests is a big problem... and I feel like the "burden of reviewers" on MSE is exceedingly low already. Maybe if this becomes a proven issue down the line it's worth making more specific rules around requests. At the end of the day, I just don't think anyone proposing a feature request with truly excellent reasoning should be penalized or gate-kept from posting simply because someone with terrible reasoning for the same idea posted a month (or a year, or 7) ago.
    – zcoop98
    Commented Jul 18, 2022 at 20:55
  • Very good arguments. Those 11k at 25CV/day equate to 30m to 1h for the close voter casting the first CV (the first eval and dup finding is usually more trouble than reviewing an item in the queue). And we'd be talkin' about an efficient close voter (taking 1-2 minutes/post). Assuming the other 4 also take 1-2minutes, it would take roughly 1 year wasting 1 hour/day (all minimums) times 5 users to take care of it (if FRs aren't so confusing and the dups so far fetched you'd waste 5 minutes per 1 item)... So that's the magnitude of that problem.
    – bad_coder
    Commented Jul 18, 2022 at 21:28
  • Lets take another look at it: the Q makes the "-8 not on the front page argument". I don't think it's entirely earnest to consider those -750 Qs (possibly some of the worst and most misguided FRs of all times) divide by 50% for dups, and discount everything that's a sure no-go, we're likely left with 20 or 30, at best. So I question the original statement (of not posting an answer and placing a bounty) based on the -8 argument.
    – bad_coder
    Commented Jul 18, 2022 at 21:38
  • 1
    Apologies @bad_coder, I wasn't intending to minimize the work cut out to clean up old FQ's. When I said the burden is low I intended to refer to general review queue traffic, not going out of our way to dig up and close old FQ's. The review queues on Meta.SE are almost always empty, which to me appears to be "an exceedingly low burden" broadly construed. If the community wanted to make a concerted effort to close all of those questions, you're absolutely right, it would be anything but a small, inconsequential task.
    – zcoop98
    Commented Jul 18, 2022 at 23:10
6

I guess part of the problem is very much site culture. We like things a little too neat and tidy. Ideally a better, more timely request shouldn't really be closed against an older terrible ones.

There are situations where It makes a ton of sense for a feature request to be reviewed but

That prior request, though, made quite a weak argument in favor of making the change, which has been quite disagreed by the community

Isn't a great one on its own. It is part of a reason to try to bring up something again, but not on its own. I think a more important thing to consider is - whether it is realistic that the revived feature request would result in the issue being reviewed on the end of the folks making a decision.

One thing I can think of is to try and get the SE team to officially decline the prior request

Which is likely to result in frustration for all involved, especially if the goal is to have the request accepted in general.

I'd also posit that community popularity (overall votes), dupe closure (one to 5 votes) and actually having a popular request of any sort, no matter how sensible, are all... unrelated. There's popular posts that'll never/be unlikely to happen, highly upvoted dupe closures (or unpopular posts reopened) or requests from the community that only happened because they aligned with the company's direction/convenience.

That's to say - Its not just 'about' bringing up a matter again in a popular fashion (and tbh, that can circumvent folks closing zealously) - it's about bringing it up in an effective fashion to make the change happen.

I realize its a bit frustrating to wait - and sometimes it feels like things are taking too long, but it's as much about the 'long game' than trying to bring up topics of importance without a definite chance of them being picked up. Some of my pet SE "wishlist" has been stuff I've been quietly pushing for years or months and some of it might never happen. Some of it has, so it's very much a matter of 'right time, right years'.

As such, I would say - work at the 'big picture' and bring it up when it's on the roadmap in the context of current activities referencing the past posts and the changes of circumstances.

Improve this answer
4

One possible argument in favor of posting new FRs would be that if the original FR became "unsalvageable" because it's:

  1. poorly written;
  2. full of noise;
  3. old;
  4. and mostly besides the point...

then if all the above criteria are met I'd suppose folks might enjoy a fresh FR post.

But, are there a few problems?

  • Criterion 3. The "old" criterion in SE's timeframe would be a minimum 2-3 year waiting period; otherwise it wouldn't make much sense, because the same FR reposted every year doesn't add much and surely would become tedious for regulars.

    E.g. The original Dark Theme FR took 9 years to completion. Would MSE readers have gained anything from 3 or 4 versions of the same FR? I think not, and I also think it wouldn't have changed anything.

  • Criterion 2. Personally, I enjoy a short and concise FR. If we introduce a logic of reposting, what will happen is that each subsequent FR will get more verbose than the previous one; piling on the reasons doesn't fundamentally change or add to them. (An interative-incremental logic will lengthen reading and research times - likely at no gain nor interest.)

  • Criterion 1. There's no guarantee that by superseding a previous FR any new answers will be better than the old ones. Or that the new FR will be better than the old one, for anyone other than the reposting OP (who'll likely cling to the facts of verbosity and complexity - more arguments and more intricate arguing.)

  • Criterion 4. I'm personally suspicious of this, maybe for 1 single reason: We've seen so many mods and high reps repost the same Nth dupe answers to the same Nth dups questions with little to no variation or gain that if we relax rules for FR duplicate posting, the most plausible prediction is we'll see the exact same logic repeating of established users trying to outdo the previous canonicals on a given subject.

You don't give any good example posts.

The post you link to refers to the The Follow Questions and Answers feature. Over the last couple of weeks I was voting to close some old posts, and I must have voted to close up to 20 FRs that were all requesting that precise feature.

as if its score is low enough it will never get seen on the home page

Don't bounties bump posts to the first page?

The presence of the prior weak request essentially hinders my ability to properly present my stronger arguments for the feature.

You can edit the question or post your own answer.

but it's generally a fruitless action if the original request was received negatively

You would have to present examples of FRs that were so poorly received there's no chance of the trend being reversed.

Improve this answer
0

You must log in to answer this question.

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