Track feature upvotes over time

[rviscomi]

We're experimenting with giving developers the ability to upvote features that they're interested in. In addition to the obvious developer signal of the current # of upvotes, it would also be useful to be able to track this number over time, ideally by day. That data would be especially useful to see how the rate of interest has changed and when particular moments of interest occurred.

Example use cases:

• Sort and filter the features that have gotten the most upvotes in the past X days as a way of seeing "what's hot"
• See how changes in the number of browser implementations affect the rate of developer interest in a feature
• Correlate surges in upvotes with the timing of influential posts, for attribution and measuring impact

If I were to prototype something like this, I'd use Apps Script on a daily trigger to query the GitHub API for all issues, extract the number of upvotes, save the results to Google Sheets, and visualize it in a public Looker Studio dashboard.

cc @foolip @atopal

[foolip]

Thanks for filing an issue to track this @rviscomi!

I like the "what's hot" idea and it remind me of the Recent column in https://foolip.github.io/spec-reactions/. There I used 90 days and I think I picked this number because it's roughly a quarter.

For a prototype I could also fork https://foolip.github.io/spec-reactions/, which I did for https://foolip.github.io/interop-reactions/ scoped to issues in a single repo.

Since the GitHub API gives the creation time of each reaction, visualizing the "rate of developer interest" would be useful I think, and probably Google Sheets is a faster way to prototype that than building graphing into the big table I made.

[foolip]

#7 is my proof-of-concept for just creating an issue per feature. This was discussed in the WebDX CG meeting last week. @tidoust are the notes from that available somewhere in addition to the doc attached to the meeting invite?

[foolip]

I see it's a public doc, and the relevant parts are here if you search for "Collecting developer signals".

[foolip]

In the discussion last week, @lolaodelola had concerns about browser vendors pushing for things that are good for them, but not for the web. @jgraham suggested that we start by excluding anything where we already have negative standards positions.

That data is maintained by @captainbrosset at https://github.com/web-platform-dx/web-features-explorer/blob/main/additional-data/standard-positions.json