How to handle a resubmission of a feature request?

Question

Let's take an example.

tvanfosson posted a feature request an hour ago about showing the reason the type of close vote each user voted for.

This was suggested by me about a week ago and I agreed with dgr that it would clutter up the screen and accepted his answer.

When I saw tvanfosson's feature request I immediately saw that his suggestion would solve the clutter issue that I had with the first request.

My original request was declined about 30 minutes ago but let's imagine this as a scenario where the original was declined before the 2nd suggestion was posted.

How should we handle a resubmission, that is a re-imagining of the idea that tries to solve some of the issues of the original, not a duplicate.

• A new question with a link to the original. This would allow for a separate discussion and leave the original intact. And this idea could then be accepted or declined on it's own. This would scatter the commentary about the idea itself around the site, so a person looking for one place to discuss this would have a hard time.

• An answer in the original. This would bump the original to the top again to allow further discussion of the original item. This would keep the suggestion of the idea in one place to be evaluated perhaps at a later date. But this idea has some flaws.

  • An answer doesn't allow for as good of a discussion (via comments)
  • If a feature request is long and the discussion is long, a new user would have a hard time distinguishing between commentary and a new suggestion.

I would love to hear your take on this.

Answer 1

A new question with a link to the original.

This.

SO doesn't work all that well for extended discussion. Re-opening an old, potentially-crowded question with new ideas seems like a good way to see those ideas ignored or lost in the noise.

There's a bit of precedent for this on SO already... I've often seen it suggested to those who are posting questions nearly identical to existing questions, but with some key difference. By explicitly linking to the exiting question, and describing why theirs is different, they're able to avoid wasting time on repeated discussion.

Answer 2

As I can attest from experience, you can't always know when something has been submitted as a request previously. I am pretty rigorous about checking for potential duplicates before I ask a question, though in this case the requested feature solves the same problem but is not the same request so I probably would have submitted it anyway. I'm reasonably sure that I never even saw the other request in the potential duplicates list.

Given this scenario, I suggest that we take what will most likely naturally occur anyway and let the new request stand on its own. When (if) a potential duplicate is found, we use the regular close mechanism or add references to previous, similar requests as they are found.

Answer 3

Sure the SO engine is not made for discussions. Both ways have flaws. But I like the "An answer in the original" approach better.
I try to keep things in one place. Even with a link to the old question, people will argue about stuff, which was already done in the orignal post. Too much scatter, too problematic to follow the stuff, if you ask me.