[ifonline]

Originally Posted by Brian

Support for contacts actually got the first customer request in 2006, not 2007. :-)

Contacts were at the top of the list when I originally mentioned it, but there are other requests that are more popular now; contacts are in the #10 slot. The current top item has twice the votes that contacts do, and was entered more recently.

In other words, the Contacts request was at the top of the list years ago, but because it was not acted on, other more recent requests moved ahead of it? That's what it sounds like to me.

[Brian]

We're pretty far from the original topic of this thread now. Welcome to continue the "why vote?" discussion, but I'm moving it into the lounge.

[Brian]

Originally Posted by ifonline

In other words, the Contacts request was at the top of the list years ago, but because it was not acted on, other more recent requests moved ahead of it? That's what it sounds like to me.

You pick some stuff to work on, you do the work. As you're working to satisfy one set of requests, more requests come in. The list changes, and you don't drop everything every time it does or you'll never ship.

We spent most of a year, for example, working on a whole mess of related issues that fall under the heading of "make sync faster". Folks don't think of that as a feature request, but we heard loud and clear that customers wanted it, so they got it. :-)

[ifonline]

Fair enough, except that method doesn't take into account #1 requests that fall off the RADAR because people get tired of waiting (and possibly assume that it will never get done anyway) so they move on to new requests.

I know it's not easy. I'm just playing a bit of devil's advocate here.

[whpalmer4]

Originally Posted by ifonline

Fair enough, except that method doesn't take into account #1 requests that fall off the RADAR because people get tired of waiting (and possibly assume that it will never get done anyway) so they move on to new requests.

The request doesn't go away just because you lose interest.

[ifonline]

No, but since requests are handled top down, previous top requests that have been bumped off due to a delay in processing are not handled before the newest top requests. Again, if the request was bumped off due to customers moving on to new requests thinking that the old (previous top requests) are being ignored, well...

[whpalmer4]

So picture this: you are in Omni's conference room with the rest of the OmniFocus product team, and the topic of the meeting is to decide a rough outline of what is going to be in OmniFocus 3. One team member summarizes the top 10 feature requests. There is a request for X, which has 150 votes. There is a request for Y, which has 250 votes, even though all of the votes are more recent than many of the votes for X, because Y relates to a feature that wasn't even in the product when some of the requests for X arrived. You've only got resources to do X OR Y, not both. Everyone agrees that both are things that would improve the product comparably. Why wouldn't you do the one that more people have felt strongly enough about to request, even if the other one had been around longer? What does it matter that something might have been the top request at some point in the past, if it is no longer?

[ifonline]

Are you suggesting that if a request has held the top position for, say, three years but hasn't been acted on for whatever resource allotment reasons, and after three years something takes over the top spot, the new top request should be handled first? I completely disagree. Holding the top spot should obviously make it a priority, but I would also argue that longevity at the top spot should be a factor in deciding the next step to take.

There is obviously no easy answer, but simply brushing off a long-standing request because it no longer holds the magical top spot is absurd.

[whpalmer4]

I am indeed saying that when Omni looks at the database on October 1 to decide what to build next, the most requested feature as of October 1 makes more sense to build than the most requested feature at some point in the past. Most utility to the largest audience trumps any playground notion of "but I asked first, it's my turn!". If you don't believe that, why shouldn't they take it to the logical extension of your argument and implement in a strict FIFO manner, regardless of the number of requests?

Argue with me all you like, but Brian has clearly stated that it is the number of expressions of interest that drives their prioritization. I'm sorry if your pet feature has been eclipsed by something else. That is a largely unavoidable drawback to not having your own captive development group.

This whole discussion probably ought to be moved off to the lounge...

[whpalmer4]

One factor that is muddying the cognitive waters here is Omni's policy of delivering substantial additional features at no additional cost. If you had to hand over real cash money to get a new feature, do you not agree that Omni should prioritize those features which have the most clients offering to pay for them? In our situation, we've pooled that money (paid when we purchased as part of the premium price), and Omni is spending it to develop features that benefit as many of us as possible.