General discussion

[DataStrategist]

Excellent work. I'm Amit Kohli, the guy that recommended this on QS. This is really cool, great job! So a couple of things:
1) how to keep this list up to date
As you mentioned, pull requests... having a few people jumping on here and there should do the trick? Let's try.
2) how to harvest relevant metadata so that we can know properties about them to help users decide
Hard... I can help scrape and build an interface w/ pics etc... but I don't know from where to pull the metadata?

[woop]

Thanks Amit.

1. Sure
2. Can you clarify what you mean by metadata? Is this data relevant to the items in the list?

[DataStrategist]

Yeah... so it would be a good tool to provide a list of stuff with it's properties... so for example, I want a watch that is waterproof and provides data though an API. Then having some sort of interface with these properties filterable... so that you can easily summarize your list according to the properties you're interested in.

[woop]

Ok. I get what you are saying. That's a good idea, but I'm wondering how we can achieve that given the limitations of GitHub. Otherwise we can use the readme as the base list and have more detailed page(s) using GitHub Pages.

[DataStrategist]

Yeah, the readme is the raw product, then I was thinking of building something using isotope.metafizzy.co to visualize the results... but how to harvest the info? :-\

[woop]

Now I get it. That's a great idea.

As a start I think we should worry about the data later. Just getting a proof of concept up for the front-end with manually input data would be a good start. Worst case the data would need to be maintained by hand.

[DataStrategist]

OK. I'll come up w/ something. It'll take a lil while... I'm a bit
bombarded with projects, but I won't forget! If you or anyone else wants to
get started, no prob.

On 14 September 2016 at 20:00, Willem Pienaar notifications@github.com
wrote:

Now I get it. That's a great idea.

As a start I think we should worry about the data later. Just getting a
proof of concept up for the front-end with manually input data would be a
good start. Worst case the data would need to be maintained by hand.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#1 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHuBi2cn3yNBkyTLJCh1A-OcMdffPalMks5qqIqhgaJpZM4J7_A7
.

~ शांति ~

+233 (0)20 758 4266
Skype: amit.kdr

[garyisaacwolf]

I'm just catching up on Forum and saw Willem's post. This is great, I'll do what I can to help!

[DataStrategist]

Hi @garyisaacwolf welcome for sure! Do you have some ideas? Or would you like to help with some existing ideas?

This may be a good overall addition to the complete list - plus source code is provided:
https://github.com/onejgordon/flow-dashboard

[markwk]

@DataStrategist This would make a great display: https://isotope.metafizzy.co/

I think if we want to provide a more exploratory display and visualization of all the QS tools, we would first need to start storing all the items in some kind of consumable or machine readable format, like JSON. Alternatively we'd need to write a parser to convert the Readme into a CSV or JSON type thing.

What we could do is write a script convert that JSON dictionary list into a README or HTML and finally also as a html display with Isotope.

[DataStrategist]

difficult part of using isotope is that you more or less have to reconstruct the thing from scratch everytime... isn't it? Like the options are embedded in the javascript. I don't have time for this, but if you wanna give it a whirl, go ahead.

[markwk]

Probably would want to write a parser to do the heavy lifting. This awesome list on public data sets probably has some start code and structural changes to make it possible: https://github.com/awesomedata/apd-core

[woop]

Like you said, having json (or yaml) as the source of truth would probably be easiest. Then you build the readme and whatever other static sites you want from that, and commit it.