search

publiclab / plots2

a collaborative knowledge-exchange platform in Rails; we welcome first-time contributors! :balloon:
https://publiclab.org
GNU General Public License v3.0
957 stars 1.83k forks source link

Tool development and problem definition communication on the website #260

Open steviepubliclab opened 9 years ago

steviepubliclab commented 9 years ago

Compiling the places we've talked about tool development during the Feb 5th organizer's call. These are the categories we discussed. The ways in which "the state of the tool" could be more clearly defined on the PL website:

Maturity/status: it there a proof of concept, is it replicable? This could include sharing info about the state of the tool as defined in the stages below (they need definitions and can change)

Other useful info::

Other ideas:

Example tool we tried to apply this to:: http://pad.publiclab.org/p/spectrometer

jywarren commented 9 years ago

There's also some good images from many older related conversations, and some examples and mockups of how we might indicate state here: http://publiclab.org/wiki/tool-development

pulse

And this type, which could be done now, and implemented based on tags or powertags, very easily:

image

ebarry commented 9 years ago

A related idea, inspired by FarmHack:

"I Built This Tool" button on tool pages. The button would open a specially tagged research note posting form that would associate your version of the tool with the tool page. This would allow browsing of all the localizations of a tool from the canonical (such as it is) tool page.

To encourage this, FarmHack is planning to make a "field observation app" perhaps built off EpiCollect to make it easy to take pictures of tools in use, add notes on how what you built is different/customized for local conditions, and include the location where the tool is in use.

jywarren commented 9 years ago

Cool! Maybe "I've built one of these" as the wording, since at first glance I thought it meant the original author of the tool.

ebarry commented 9 years ago

Adding some points of reference from FarmHack:

  1. Overall, FH is revamping tool pages to focus on problem statements. Specifically, every tool has to have a problem statement. A tool can have multiple problem statements. Problem statements themselves are searchable to help people find the tools that have been created for the problems they are seeking to address.
  2. FarmHack's current tool overview page http://farmhack.org/tools (equivalent to http://publiclab.org/tools) clearly shows the Stage of Development along with each tool listing.
  3. FarmHack's new tool library (currently under rapid development) http://farmhack.org/library/tools and http://farmhack.org/node/add/tool asks tool creators to fill out a series of fields including:

A) TOOL CONCEPT (including a required radio button on "tool stage: Concept / Prototype / Ready to build", a required free text tool description, and a dropdown to chose to associate your tool with other Problem Statements that others have submitted either while creating other tools or looking for applicable tools.

B) DOCUMENTATION,

C) USER MANUAL,

D) RELATED TOOLS

E) SKILLS,

F) COMMERCE (who is selling ready-made versions of this tool), with potential fields including:

screen shot 2015-09-08 at 1 41 41 pm

ebarry commented 8 years ago

Point of reference on "revealing open problems" not solutions: http://worrydream.com/ClimateChange/#tools-finding The author asks "How do we surface these problems? How can an eager technologist find their way to sub-problems within other people’s projects where they might have a relevant idea? How can they be exposed to process problems common across many projects?"

dbeavers commented 8 years ago

This is a very interesting link! Thank you Liz!

gretchengehrke commented 8 years ago

This is great stuff. I want to contribute some thoughts we discussed at the fall 2015 staff retreat that I wrote up in a research note: https://publiclab.org/notes/gretchengehrke/10-07-2015/intended-purposes-for-different-tools-and-techniques. Also, Liz and I were chatting about having three sorts of groupings of information about each tool (and perhaps each method / technique as different methods develop to use tools in different ways): (1) tool intended purpose / "tier" of tool (e.g. for scientific data collection, for qualitative use, etc) and the status of tool development (e.g. concept, alpha, beta, ready for use, etc) (2) usability and community support level (3) specs required for prime-time data collection for a given problem that the tool is trying to address in some way / how the use of this tool could fit into advocacy or data collection for a certain topic

ebarry commented 8 years ago

This is great @gretchengehrke , thanks! If we were going to make a quick and dirty spreadsheet where each row was one of our tools, what would the columns be?

ebarry commented 8 years ago

could we include a column (or a few columns) about what kind of software is needed to analyze/present the data produced by the hardware, and the software's state of usability?

jywarren commented 8 years ago

ooh i like that idea, liz.

mathewlippincott commented 8 years ago

These are our four different tool development activities that should be on tool pages. Each of these can reach a stage of completion, and when all four work together, then a tool is ready to adopt.

screen shot 2016-03-15 at 10 54 56 am

tonypubliclab commented 8 years ago

Important question to add to this: Is there an existing tool that already solves the problem?

Awareness of current tech dev, including literature and what's the latest in maker/hacker circles, both for sale and in the pipeline. I bet we'd frequently realize we just need to send communities a link to a store, not invent a thing.

Maybe this is part of literature review step: current tools review?

ebarry commented 7 years ago

Updates from late summer and fall 2016!

Copying in @devinbalkind who has advised FarmHack on their Tool API

devinbalkind commented 7 years ago

I'm quite keen on seeing directories of "tools" made API accessible so we can more easily mash up data between repositories of tool information.

Besides FarmHack.org and PublicLab.org, I also deal with tool directories for the humanitarian space (ex. https://resiliencecolab.org/tools/) and nonprofit software (https://socialsourcecommons.org/tool/by_popularity). I also think the nice folks at draftanimalpower.org will be putting together a tool directory in the not too distant future.

After doing analysis of platforms offering tool information (Tools Comparison sheet --> https://docs.google.com/spreadsheets/d/11Bk3JZlLk_6u2rkZU4CLV0gX7_OCkwB3-cNzgSvBKuU/edit#gid=0), I can tell you the following fields are in almost all of the tool directories:

Name Image URL (outside website) Description Tags

If all these directories can speak compatible languages, I think we could see some really interesting cross-pollination.

So, my question: can you all make (at least some part) of your tool info API accessible?

jywarren commented 7 years ago

Hi, we have various APIs, but I'm not sure if they're in a helpful format. Perhaps we need one specific to wiki pages tagged with "tool"?

https://github.com/publiclab/plots2/wiki/API

On Mon, Dec 5, 2016 at 9:59 PM, Devin Balkind notifications@github.com wrote:

I'm quite keen on seeing directories of "tools" made API accessible so we can more easily mash up data between repositories of tool information.

Besides FarmHack.org and PublicLab.org, I also deal with tool directories for the humanitarian space (ex. https://resiliencecolab.org/tools/) and nonprofit software (https://socialsourcecommons.org/tool/by_popularity). I also think the nice folks at draftanimalpower.org will be putting together a tool directory in the not too distant future.

After doing analysis of platforms offering tool information (Tools Comparison sheet --> https://docs.google.com/spreadsheets/d/11Bk3JZlLk_ 6u2rkZU4CLV0gX7_OCkwB3-cNzgSvBKuU/edit#gid=0), I can tell you the following fields are in almost all of the tool directories:

Name Image URL (outside website) Description Tags

If all these directories can speak compatible languages, I think we could see some really interesting cross-pollination.

So, my question: can you all make (at least some part) of your tool info API accessible?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/publiclab/plots2/issues/260#issuecomment-265047196, or mute the thread https://github.com/notifications/unsubscribe-auth/AABfJ7PnX3HvrHihFReBgE5Tt3oV-MHbks5rFM-BgaJpZM4D2DWH .

jywarren commented 7 years ago

We could open a new issue, suggesting porting this tag-based RSS feed over for wiki results as well:

https://github.com/publiclab/plots2/blob/master/app/controllers/tag_controller.rb#L185-L207 https://github.com/publiclab/plots2/blob/master/app/views/tag/rss.rss.builder

And/or providing an XML/JSON endpoint for it too. I'm not that familiar with Grape/Swagger, but if it's easy to provide such an API using that, we could try that too.

On Tue, Dec 6, 2016 at 9:50 AM, Jeffrey Warren jeff@unterbahn.com wrote:

Hi, we have various APIs, but I'm not sure if they're in a helpful format. Perhaps we need one specific to wiki pages tagged with "tool"?

https://github.com/publiclab/plots2/wiki/API

On Mon, Dec 5, 2016 at 9:59 PM, Devin Balkind notifications@github.com wrote:

I'm quite keen on seeing directories of "tools" made API accessible so we can more easily mash up data between repositories of tool information.

Besides FarmHack.org and PublicLab.org, I also deal with tool directories for the humanitarian space (ex. https://resiliencecolab.org/tools/) and nonprofit software (https://socialsourcecommons.org/tool/by_popularity). I also think the nice folks at draftanimalpower.org will be putting together a tool directory in the not too distant future.

After doing analysis of platforms offering tool information (Tools Comparison sheet --> https://docs.google.com/spread sheets/d/11Bk3JZlLk_6u2rkZU4CLV0gX7_OCkwB3-cNzgSvBKuU/edit#gid=0), I can tell you the following fields are in almost all of the tool directories:

Name Image URL (outside website) Description Tags

If all these directories can speak compatible languages, I think we could see some really interesting cross-pollination.

So, my question: can you all make (at least some part) of your tool info API accessible?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/publiclab/plots2/issues/260#issuecomment-265047196, or mute the thread https://github.com/notifications/unsubscribe-auth/AABfJ7PnX3HvrHihFReBgE5Tt3oV-MHbks5rFM-BgaJpZM4D2DWH .

devinbalkind commented 7 years ago

A JSON endpoint to

wiki pages tagged with "tool"

would enable me to make some stone soup so, yes! How can I help?

jywarren commented 7 years ago

I think we could start by modifying this show method in the tag controller:

https://github.com/publiclab/plots2/blob/master/app/controllers/tag_controller.rb#L16-L51

This ought to be in a new issue, but please feel free to copy over, or ask me and I can create one!

We could break out the response by format type, as is done on this line of Spectral Workbench:

https://github.com/publiclab/spectral-workbench/blob/master/app/controllers/spectrums_controller.rb#L72-L76

That'd make it possible to send a request similar to the usual one for wiki pages, for example:

https://publiclab.org/wiki/tag/pm

But add a format, like:

https://publiclab.org/wiki/tag/pm.json

And you'd receive @nodes in JSON format as a result.

We'd want to write a functional test for it too, and an API page entry, but that should be pretty easy and I can add info on that too once we have a unique issue up.

Thanks!!

On Tue, Dec 6, 2016 at 1:47 PM, Devin Balkind notifications@github.com wrote:

A JSON endpoint to

wiki pages tagged with "tool"

would enable me to make some stone soup so, yes! How can I help?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/publiclab/plots2/issues/260#issuecomment-265235990, or mute the thread https://github.com/notifications/unsubscribe-auth/AABfJ4sVaS3Q6gCRd-2FPS9VpC8Dxzycks5rFa22gaJpZM4D2DWH .

jywarren commented 7 years ago

Done in #1069 (the API part Devin asked about)

grvsachdeva commented 5 years ago

@jywarren can you sum-up the goals here? Thanks!

devinbalkind commented 5 years ago

An original - but slightly dated - vision is here: http://toolapi.org/

Recently I've begun working with the http://qri.io team to re-enliven the idea of multiple open source/appropriate tech tool directories mashing their data together to create a decentralized stackshare.io-style system. Expect more updated over the next few weeks on our progress.

On Mon, Mar 25, 2019 at 11:41 AM Gaurav Sachdeva notifications@github.com wrote:

@jywarren https://github.com/jywarren can you sum-up the goals here? Thanks!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/publiclab/plots2/issues/260#issuecomment-476253923, or mute the thread https://github.com/notifications/unsubscribe-auth/AAbHl6YIC1DyysTiRN0_Z0tDmxrTXzCOks5vaO4qgaJpZM4D2DWH .

-- Devin Balkind @devinbalkind devinbalkind.com

stale[bot] commented 3 years ago

Hi :smile:, this issue has been automatically marked as stale because it has not had recent activity. Don't worry you can continue to work on this and ask @publiclab/reviewers to add "work in progress" label :tada: . Otherwise, it will be closed if no further activity occurs in 5 days -- but you can always re-open it if you like! :100: Thank you for your contributions :raised_hands: :balloon:.

ebarry commented 3 years ago

While this is an old issue, the concepts being discussed here are still active and i do not want to bury this record. Removing 'stale' label. Thanks!