12

Often there is a lot of discussion about a new feature-request and it lays around and won't get implemented not knowing if it is good or not.
Or the community really likes a feature, upvotes it a lot but the team is not so sure this would be a benefit for the site.

Would it be practical to try some feature-requests for a while and see if they work?

This would of course mainly apply to those not needing a lot of implementation. Take this request* for instance. It does not need a lot of work. It could run for a week and afterwards a little statistic could show if it did some good or not.

Would you say we should consider such a practice for some feature-requests?

Yes, it is one of mine. It is just an example.

  • I'm not sure this can be answered globally. It'll really depend on the nature of the feature request, what areas would be affected, the potential damage/confusion it might cause for existing users and/or anonymous users, etc.... for example, a rule change or new tool may be very hard to revert because it takes time for word to spread. But a rule change that affects anonymous users only might not pose a problem at all, because the affected audience usually doesn't have a relationship with the site and its culture – Pekka supports GoFundMonica Dec 29 '13 at 19:36
8
+50

A few things to keep in mind with feature requests.

  1. Some requests are relatively simple items. These items are updated and rolled out daily. Most of these are minimal effect and effort type of items.
  2. Some requests are big changes. Because the SE network is so big, any major change—as simple as it may seem—requires a lot of thought and effort. Every change has technical, visual, and practical impact on user behavior, ease of use, and the overall goal accomplishment of asking and answering questions easily. After a lot of planning these features are typically rolled out in stages. They're tested until we're satisfied with the improvements. Generally it takes a few weeks to get actionable data for any substantial change. The updated login pages are a recent example of this.
  3. Some requests aren't big requests in and of themselves, but they have large impacts. I imagine that the request you linked to falls more into this area. I can't attest to the ease of implementing such a feature, but I imagine it wouldn't be hard to implement. Yet it may have unintended effects. Will it comprise previous data? Will it change user behavior? Also, is the reward taking the time to implement this worth the investment of resources given all the other requests, features, and bugs that we are managing?

Another possible answer is that we saw the request, it's a relatively simple request, and it's in a queue somewhere waiting to be worked on. We can't promise when things will get worked on because things come up. We do test new and updated feature-requests regularly. Given how big the network and feature-sets are though, you may not bump into it.

4

In general I appreciate this approach and I think for some features they are using or have used this approach (as an example the new TopBar or changes to the Closing and flagging of posts were first introduced on Meta), but at least there needs to be one (or more) Stack Exchange developer(s) to actually develop and maintain such tryouts. Some features are easy to implement, while others need more time and I'm not sure if it will pay off.

You must log in to answer this question.

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