Tool development and problem definition communication on the website

[steviepubliclab]

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:

• What is the cost of the tool? $5-50-100-150-200
• How DIY is the tool, (what skill level would you need to be to get it to work): Make: Beginner-Intermediate-Advanced-Hotshot
• How hard/easy is it to use: Beginner-Intermediate-Advanced-Hotshot
• Is there teamwork required?
• How hard/easy is it to Understand: quick-reasonable - requires dedication - it’s like a part time job alternatively:: how long does it take to get up to speed (hours)?
• How difficult is the tool to Interpret: Beginner- Intermediate-Advanced-Hotshot
• How shareable/accessible is the data? (what do you need to access the data physically?) ?internet, computer, sharable

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)

• Problem definition
• Data Standard/Literature Review
• State of the Art/Literature Review
• Design thinking/Prototyping
• Field Assessment
• Outcomes Assessment of Solutions
• Field tested
• Replicable
• Used in # of situations

Other useful info::

• number of contributors to the tool?
• amount of recent development activity

Other ideas:

• A way in which users users vote on this? add stars?
  • tag names (ignore, just note to self for developers): interpret:intermediate, make:beginner
• Way to move forward::
  • Break into tool groups and choose where to draft new text (talk page, sandbox, here in this doc)
  • http://publiclab.org/wiki/sandbox
  • table layout (kinda boring): http://publiclab.org/wiki/sandbox#Project+Pulse

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

[jywarren]

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

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

[ebarry]

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]

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]

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

• THIS TOOL IS A COMPONENT OF THESE OTHER TOOLS
• THIS TOOL AN ASSEMBLY OF OTHER TOOLS
• THIS TOOL IS A BRANCH FROM THESE OTHER TOOLS
• THIS TOOL MERGES THESE OTHER TOOLS TOGETHER

E) SKILLS,

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

• Tools for creation and repair • Materials sources • Requests for proposals, bounties, reverse bounties • Crowd funding links and campaigns • Software • Kits for sale • Finished products • Help wanted etc.

[ebarry]

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]

This is a very interesting link! Thank you Liz!

[gretchengehrke]

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]

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]

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]

ooh i like that idea, liz.

[mathewlippincott]

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.

[tonypubliclab]

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]

Updates from late summer and fall 2016!

• activities and #upgrades grids prototyped and installed on major research areas: https://github.com/publiclab/plots2/issues/485

• discussion on renaming /tools to be broader: https://publiclab.org/notes/liz/09-30-2016/should-tools-be-renamed-to-methods-techniques-or-something-else resulted in https://github.com/publiclab/plots2/issues/857
• now working on a template for new methods to be added, drafting here http://pad.publiclab.org/p/hedwig and https://publiclab.org/wiki/method-template

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

[devinbalkind]

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]

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]

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]

A JSON endpoint to

wiki pages tagged with "tool"

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

[jywarren]

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]

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

[grvsachdeva]

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

[devinbalkind]

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]]

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]

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!