Voting is something I don't think we'll need to add. I'd rather rely on Tokens/Comments/Subscribers as measures of interest in completing a task.

@iodragon I am assuming this is what you wanted to accomplish this task, if something else let us know.

You can view the objects with the most tokens here, although this currently includes closed/resolved objects and includes objects of all types:

https://secure.phabricator.com/token/leaders/

For "interest", do you want to come up with a formula for "interest points" and I'll run the numbers and see if it's good? I worry that any synthesis of several factors will be inaccurate (because the signals will only correlate to what we're after, not imply it) and sort of confusing (because it won't be obvious why something has interest points). For example, if we use:

interest points = 3 points per comment + 2 points per subscribe + 1 point per token

...then the most "interesting" open tasks are (columns are Task ID, "Interest Points", Task Title):

 T603    200 Support permissions/policies in all Phabricator applications
 T390    168 Implement Project Types
T1315    141 Phacility Launch Status
 T945    137 Allow closing tasks by commit message
T1261    130 PHP / HPHP Compatibility Issues
 T635    115 Removes support for parsing XHP tags
T1591     94 Differential "buoyant" header has been temporarily disabled
T3583     82 Fix the Swamp of Suck that is the home page content panel
T1960     81 Breadcrumbs or similar UI-navigation for getting back to the ticket overview
 T182     73 Commit into repository directly from differential

This seems okay, but not great. T603, T390, T1315 and T182 (positions 1, 2, 3, and 10) are probably legitimately "interesting", but the other 6 tasks are not really and just have a lot of activity for other reasons. Overall, I don't think this list reveals anything interesting or insightful, and it doesn't make me want to take any concrete action to change priorities.

We can try other formulas and see if we can come up with something better if you have different ideas for measuring interest, my formula is obviously quite crude.

Computation of any sort of synthetic interest/heat score needs to happen in the Fact pipeline, which has a fair amount of work to do (T1562).

Here's the script I used to compute "interest points":

{P888}

Maybe it's the comments that are skewing it. It's a high number and can have a high count. I sort of assume voting a proxy for unique user interest. So maybe it's just subscriber/token?

For:

interest points = 2 points per subscribe + 1 point per token

...here's the top 10:

 T603    145 Support permissions/policies in all Phabricator applications
 T390    107 Implement Project Types
T1315     99 Phacility Launch Status
 T945     73 Allow closing tasks by commit message
 T635     57 Removes support for parsing XHP tags
T1261     54 PHP / HPHP Compatibility Issues
 T182     51 Commit into repository directly from differential
T1049     48 Implement Harbormaster
T1591     46 Differential "buoyant" header has been temporarily disabled
 T418     43 Integrate Maniphest custom fields into more interfaces

This isn't much different and seems at least as bad to me.

This was also requested in http://fab.wmflabs.org/T414 (as Bugzilla has a not-very-obvious Voting functionality which never convinced me, but obviously it's used by some folks).

Assuming that number of tokens on a ticket could be one helpful community data input for future planning and priorities in a project, https://secure.phabricator.com/token/leaders/ looks like a good start; but would love to be able to

• exclude closed tasks
• show certain types only, like tasks etc.

Shall I file two separate wishlist tasks about that, or would that also be WONTFIX?

I don't want to add object filtering options to Tokens, since the UI would be unreasonably complex (e.g., for completeness, it would need all of the options that all of the other search UIs have). We could let you "Order By: Tokens Awarded" in Maniphest, but the database is not structured in a way that allows that data to be queried in a scalable way.

From a product perspective, I'm also hesitant to make "token" mean "vote". There are some differences in the workflows: tokens require two clicks and a decision, they notify object authors/owners, and they publish to the transaction log and feed. These are probably all too heavy for a vote interaction. If you want votes, I'd rather just implement votes separately.

Feel free to file a wishlist for voting -- I don't think I've seen much other interest and I'm not personally too convinced of the value so I don't expect we'll build it any time soon, but we do have some tentative plans to revisit tokens once Phortune (payment processing) comes online. Specificaly, we want to implement some kind of bounty/tipjar/premium token feature so we can test payments in a low-stakes environment. It's possible that shakes out as "pay $1 for a vote" on this install, and "click to vote" on your install or something like that.

At Wikimedia we are not enthusiastic about votes either, and this topic is definitely a nice-to-have detail only.

In T3611#10, @epriestley wrote:

You can view the objects with the most tokens here, although this currently includes closed/resolved objects and includes objects of all types:

https://secure.phabricator.com/token/leaders/

A project-level ranking showing only open tasks would be useful for those communities paying attention to tokens.It could be offered as a "Popular items" link in the project view.