Short version:

Surface significant pending features as a first-class entity within the Stack Exchange network with mechanisms for community input and collaborative decision making. One form this could take is a "uservoice-like" site where the items are those that have gained traction in meta or are proposed by the team (i.e., user suggestions aren't directly allowed), with related chat rooms and/or meta questions and up/down voting.

Long version:

Let me describe a scenario that I think happens too frequently on Stack Overflow. A feature appears, seemingly out of nowhere; lots of people flock to meta to complain about the change; people who frequent meta a lot say "what are you whining about, it was discussed in question blah, blah, blah"; you navigate to question "blah, blah, blah" and you find a feature request to which @Jeff has responded (as often as not, not having the most upvotes) and, therein, you see the origin of the feature that just appeared.

From the outside two things appear clear. First, users are genuinely surprised by new features and changed behaviors. Second, the team is genuinely surprised that people (who care) aren't aware of these things. I attribute this to the difference between the way normal users use meta and the way the team does. Normal users don't spend a lot of time in meta; maybe we come here each day and browse around, but we're not driven to dive deep into the question pool and participate - if you're not on the team and you do this, you're left to draw your own conclusions about your normality :). For team members (and mods), meta is much more important and they do use both tools and searches to dig into meta issues and to expose ideas to the meta audience. The audience those requests finds probably depends on the time of day and, likely, the amount of attention those users give to meta (see previous aside on normality).

Additionally, feature requests are mixed in with, on meta, a vast array of other types of posts, including complaints about previous requests, support issues, bug reports, requests for features that will never see the light of day, duplicate requests for the same feature, etc. Unless you take the time to highlight or search for feature requests AND wade through the resulting morass of responses, it's easy to miss a feature request. If you don't log on to meta regularly, you have no chance - for one thing, features sometimes seem to appear within hours or a couple of days of the request being made.

My suggestion is to elevate feature requests into their own site, not as a regular Stack Exchange site, but one with a different mode of operation. Once upon a time we had UserVoice and, while it worked pretty well for certain types of questions, it failed at being an all-around support site for SO. It suffered from some the same problems I describe above. With a few tweaks, though, such a site or something similar could be made to work better as a way to collaboratively give input on the direction of the Stack Exchange platform. The key features that would be necessary are:

  1. An intake mechanism from a larger, freeform suggestion forum (meta)
  2. A winnowing process, perhaps within the team, from proposed to tentatively accepted features
  3. A related space to take discussion out of the way, i.e., we want it to be easy to see, navigate, and vote on the collection of tentative features
  4. Voting (unlimited? limited by rep?) on tentative features. On UserVoice we had 10 chits we could hand out. I think people ought to be able to vote up or down on each item, but I'd be open to ideas that tied the number of votes to participation.
  5. A means of exposing which features have been accepted. Knowing the roadmap for implementation would be nice as well.

Additionally, there would be no ability to add items (except for the team), no editing of existing items (except for the team), no answers (just voting), and no inline comment streams (just a ballot with links to offline comments).

Exposing feature requests in this way would give people who are interested (passionate) about the direction of Stack Exchange a more convenient way of participating in its direction. By letting users continue to propose features on meta, we don't place any artificial barriers to input. By only putting the realistic feature requests in the tool, we make it easy to find and give input to features that might actually have a life. Using voting (up and down) we can both provide guidance into the relative importance of said features and whether the features actually make sense, perhaps leading to more refinement. Moving discussion completely out of the way (into chat or a related meta question), we keep the browsing and voting interface clean.

  • When faced with a problem regarding transparency/community/openness, some people think, "I'll just use bureaucracy." Now they have two million problems.
    – Pollyanna
    Jul 25, 2011 at 19:38
  • @Adam - there are already existing tools for making and voting on feature requests, I just don't think they're used very well nor are they well suited to the task. I think we'd all be better served by not trying to use a screwdriver as a hammer.
    – tvanfosson
    Jul 25, 2011 at 19:48
  • I'll have you know that a screwdriver makes a fine hammer.
    – Pollyanna
    Jul 26, 2011 at 1:59

1 Answer 1


Short version

I certainly think that significant new features should be surfaced to the community for comments and review. That seems to not be happening lately. But I don't necessarily think we need a new website for that. All we need is a (moderator only) [feature-review] or [new-feature] tag on meta.

That said, I think there's a reluctance by the development team to surface new features until they are already completed, when any feedback on their design would be less useful.

Long version

Your question assumes that new features are actually driven by ideas from the user community. They may be, indirectly, but...

Let me make an analogy. Compare and contrast the design process of the C# language with that of the Java language. In C#'s case, you have one prominent company with a small language team led by a very smart benevolent dictator. In Java's case, you have a consortium driven by several large players in the Java space, each of which has a vote; design by committee, if you will.

Which process works better?

On the one hand, Java is arguably more "industry-standard," since it demands a high degree of consensus to get new features. But getting new features into the language takes a long time; the consensus-developing process is extremely slow, and features tend to be hobbled by compromise (e.g. generics via type erasure). As the language gets progressively more complex, the process must necessarily slow down as well, to make sure that new features are being integrated properly into the language, and all of the edge cases are being considered.

On the other hand, C# is a "defacto-standard" (although Microsoft has mitigated this by allowing the specification to be ECMA certified). Because the team that proposes and develops new features is small, and can be placed into a single room around a conference table for immediate discussion, new features get proposed and adopted rather quickly. The result is that the C# language evolves much faster than Java does.

In the early days of Stack Overflow, I believe that the process was more community-driven than it is now. But the community was much smaller then, and it consisted of early adopters: very smart people who understood the concept and were willing to put the hard work into making it successful. In that sense, it was a lot like C#; even though it was technically "design by committee," it was a small committee.

But Stack Overflow grew up, and then it became Stack Exchange, and it got some new stakeholders. Now the community is much larger, and that "design by committee" process no longer scales. As each new user comes in who doesn't understand why he can't do anything he wants on a Stack Exchange site, and how un-democratic the process seems to be, we have to (once again) explain to him that many of these decisions were made a long time ago, by community consensus, and that it is counterproductive to continue to rehash them.

In summary, I think as the community has grown, the development process for new features has shifted from Java style to C# style. Adding a "feature requests" website doesn't necessarily change that fundamental dynamic.

  • I'd argue that the analogy doesn't fit; designing a web site is not like designing a compiler. Compiler changes may break my stuff. Note also that my suggestion isn't to control the roadmap, but to allow a greater and more effective voice in guiding the roadmap. As such it's as much about giving the team tools to understand what their users really want as it is about giving user's a better way to participate. Note that the C# team does, through publishing the spec early, asking for input, and making preview releases available have a means to get community feedback.
    – tvanfosson
    Jul 24, 2011 at 17:53
  • @tvan: All good points. But before you build a website to solicit feedback on new features, there has to be a willingness to collect such feedback. I'm not sure that's the driving motivation nowadays. I think the team looks at the activity on the SE websites, and the feedback on general usage posted here, and derives their own features. In other words, I think they believe they are in the best position to design new features, not the community.
    – user102937
    Jul 24, 2011 at 17:57
  • that certainly may be true, but Jeff has consistently stressed community involvement in running the sites and we are currently using meta (ineffectively, IMO) as a mechanism to collect feature requests. That was one of the motivations for setting it up -- to have a better way than UserVoice to have conversations about requests.
    – tvanfosson
    Jul 24, 2011 at 18:15
  • I'm sort of confused by this answer. Are you saying that just this idea won't work, or that the community proposing feature requests (old or new) like it is now isn't working?
    – TheLQ
    Jul 24, 2011 at 18:16
  • @TheLQ: I'm saying that the question assumes that the development team wants the community to be directly involved in the design process. Unless that assumption is valid, any attempt to make a new website to get the community involved in the design process is a non-starter.
    – user102937
    Jul 24, 2011 at 18:21

You must log in to answer this question.

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