Refine Tool model & admin interface

[erictheise]

@cherylhjli created her account today and we screenshared to go over adding and managing Tools via the Django admin panel. A few issues emerged:

• the most common open source licenses should be prepopulated into the License model
• there should be help text for SPDX-related information
• it should be possible to assign relevant Sectors to a Tool
• there's the notion of User/Coop needs from a Tool, these need to be matchable to a notion of Tool provides, e.g., accounting, governance, etc.

Sectors should be straightforward to implement. Needs/Provides should also be straightforward but

• for now they'll go freeform into the Notes field
• we'll start developing a taxonomy after design crits

[erictheise]

@cherylhjli would you agree this is where we left it? Did I forget anything?

[cherylhjli]

looks good to me, thanks @erictheise!

[erictheise]

There are now twelve Licenses to choose from. Admin allows more to be added. I'm leaning heavily on spdx.org for codes and definitions.

[erictheise]

And Sectors have been added to Tools.

[erictheise]

I've added a model I'm calling Niche which feels general enough to me to serve on the Tool model (as a proxy for provides) and on the Organization model (proxying for needs) and imported the current values from @greatislander's Airtable with two caveats:

1. if a Tool has nothing but a name it has not been imported. @greatislander and I agreed on that over IRC.
2. I've not added Proprietary as a licence, doesn't seem quite right to me.

The Admin has been modified so that Tools can be filtered by Niche, License, or Pricing.

[cherylhjli]

I'm not totally understanding what "niche" is still, perhaps we can discuss tomorrow? In addition to that, I agree proprietary isn't a license, tomorrow we should also talk about how to best indicate when a software is proprietary.

[erictheise]

Sure @cherylhjli we can discuss at stand up or at the architecture meeting that's happening sometime during this iteration. But basically I'm looking at database fields and API keys and thinking ahead to when this is handed over to someone else.

Tools don't have needs, which is how the Airtable is set up. They do fulfill needs, which feels too wordy for a database field, so I'm thinking instead that they have a niche (or several niches); Loomio's is Decision making, Stripe's are in Finance facilitating payment from customers and payment to vendors.

Organizations need niche tools, so when we start matching from Orgs to Tools, I think that language will make more sense in the code & database. We can continue to label them as needs in the Organization interface.

Not a big deal to change at this stage.